Unitate 8 / 9

Automatizare, logica PLC și date senzori/IoT

Câștiguri:

  • Abilitatea de a împărți un scenariu de automatizare în listă de intrare/ieșire și pași logici și de a solicita scară/schiță ST de la AI
  • Abilitatea de a monitoriza logica PLC generată de AI în ceea ce privește blocarea de siguranță, oprirea de urgență și condițiile de cursă
  • Abilitatea de a verifica calibrarea, volumul și semnalele de eroare atunci când se interpretează datele de telemetrie ale senzorilor și IoT cu AI

Automatizarea industrială este una dintre cele mai atinse domenii ale ingineriei electrice și electronice: un PLC (controller logic programabil) citește semnalele de la senzori și acționează motoare, supape și alarme în conformitate cu o anumită logică. O eroare logică aici nu este doar o „ieșire greșită”; Un transportor blocat, o supapă care rămâne deschisă sau o oprire de urgență care nu se cuplează pot duce la răni reale. AI este rapid la conturarea logicii de automatizare, sugerând cod scară/ST și interpretează datele de telemetrie ale senzorului/IoT; Dar încuietorile de securitate și proiectarea cu siguranță sunt responsabilitatea inginerului. În această unitate, vom acoperi cum să definim scenariul de automatizare pentru AI, cum să controlăm logica PLC generată și cum să interpretăm în siguranță datele senzorului.

Configurarea scenariului de automatizare: Lista I/O și pașii logici

A spune AI să „programeze un transportor” este inadecvat. Mai întâi, separați procesul în pași de intrare (senzor, buton), de ieșire (motor, supapă, lampă) și pași logici. Această distincție clarifică promptul și face logica controlabilă.

Exemplu de listă I/O (stație de umplere simplă): Intrări: I0.0 Buton de pornire, I0.1 Buton de oprire, I0.2 Oprire de urgență (NC), I0.3 Senzor de detectare a sticlei, I0.4 Senzor de ocupare Ieșiri: Q0.0 Motorul transportorului, Q0.1 Supapă de umplere, Q0.2. gata.2) Transportor cu retur Start; Opriți transportorul când este declanșat senzorul sticlei.3) Deschideți robinetul de umplere; Închideți robinetul când senzorul de ocupare este plin.4) Reporniți transportorul; Procesul se repetă.5) E-stop sau Stop ia toate ieșirile către partea sigură în orice moment.

Solicitare slabă / Solicitare puternică

SLAB: „Scrieți codul PLC pentru transportor.” (Rezultat: adresele I/O, blocajele de siguranță și logica de stare sunt neclare; un cod incomplet potențial periculos.) STRONG: „Sugerați schița logică PLC (Text structurat) pentru o stație de alimentare pe baza listei de I/O și a pașilor logici de mai sus. ASIGURAȚI-vă că este configurată și închiderea logica prealabilă. condiție care pune toate ieșirile pe partea sigură.- Transportor și supapă „Nu creați o situație periculoasă în același timp (blocare). - Comentați fiecare pas. Precizați că acesta este un proiect; lanțul de securitate, siguranța și testarea pe teren aparțin inginerului.”

Controlul logicii PLC: siguranță, siguranță, condiții de cursă

Nu este suficient ca logica produsă să „pare că funcționează”. Urmați această listă de verificare:

control

Ce să cauți

oprire de urgență

Contact NC, de siguranță, cea mai mare prioritate, comutarea tuturor ieșirilor în partea de siguranță

Interblocuri

Ieșirile aflate în conflict nu ar trebui să fie active în același timp

starea de cursă

Sarcini conflictuale în același ciclu, situație nedefinită

starea initiala

Pornirea într-o stare sigură, cunoscută atunci când este alimentată

Cronometru/contor

Logica corectă, depășire, stare de resetare

defecțiune a senzorului

Comportament sigur în caz de rupere/scurtcircuit al senzorului

Oprirea de urgență (oprire de urgență) este punctul cel mai critic. Funcția de siguranță trebuie să fie de siguranță: adică dacă un cablu se rupe, un contact se defectează, sistemul trebuie să cadă pe partea sigură, nu este periculos. Prin urmare, oprirea de urgență este stabilită cu un contact normal închis (NC); Dacă cablul se rupe, circuitul se deschide și sistemul se oprește. În plus, logica software în sine nu este suficientă; Un lanț de siguranță hardware (releu de siguranță/contactor) trebuie proiectat și verificat de către inginer.

Avertisment: dacă vedeți într-o scară/cod ST generat de AI că oprirea de urgență este setata cu un contact normal deschis (NU) sau doar un semnal software, aceasta este o vulnerabilitate. Funcțiile de securitate nu sunt lăsate niciodată doar în seama software-ului; Lanțul hardware de siguranță și conformitatea cu standardele relevante de siguranță a mașinii sunt responsabilitatea inginerului și sunt verificate prin teste pe teren.

Condiții de cursă și mașini de stat

Logica PLC funcționează ciclic; Toată logica este procesată de la început până la sfârșit în fiecare ciclu. AI scrie uneori linii contradictorii care stabilesc aceeași ieșire într-un loc și o resetează în altul; acest lucru face ca ieșirea să pâlpâie imprevizibil (condiția de cursă). Construirea proceselor complexe ca o mașină de stări explicite reduce acest risc: sistemul este într-o stare unică, specifică în orice moment, cu tranziții dependente de condiții clare.

Interpretarea datelor senzorilor și IoT: calibrare, unitate, semnal de eroare

În timp ce datele de telemetrie ale senzorilor și IoT (temperatură, presiune, vibrații, curent) sunt valoroase pentru analiză, pot fi înșelătoare în forma sa brută. Pe măsură ce AI rezumă aceste date, trebuie să verificați trei lucruri:

  1. Calibrare și scalare. Ieșirea senzorului este valoarea ADC brută sau unitatea fizică reală? AI 4-20 mA poate scala incorect un senzor și poate confunda valoarea fizică.
  2. Unitate. °C sau °F, bar sau kPa, RMS sau vârf? Confuzia de unitate strică întreaga interpretare.
  3. Semnale de eroare. Valoare blocată, scădere bruscă la zero, citire în afara intervalului; Acestea nu sunt măsurători reale, dar pot fi defecțiuni ale senzorului/liniei. Dacă AI le interpretează ca „date interesante”, ai greși.

# Senzor 4-20 mA -> scalare a valorii fizice (gamă 0-100 °C) def ma_to_temp(ma): dacă ma < 3,5: # Sub 4 mA -> linie întreruptă/retur de eroare Niciunul # marcați ca returnare nevalidă (ma - 4.0) / (20.0 - 4.0) * 100.0, pentru citire [24.0, 2.0. 2.0]: t = ma_to_temp(citire) print(citire, "mA ->", "DEFECT" dacă t este Nimic altceva f"{t:.1f} C")

Sfat: atunci când interpretați datele IoT, mai întâi întrebați „este această valoare posibilă din punct de vedere fizic?” Pune întrebarea. Dacă un senzor de temperatură a camerei arată 300 °C, acest lucru nu este real, este probabil o eroare de calibrare/linie. Eliminați semnalele de eroare înainte de interpretarea AI.

Mini carcasă

Un inginer de întreținere are AI să interpreteze datele de vibrație IoT ale unei pompe. AI spune că „vibrația a crescut cu 200% în ultima săptămână, risc de defecțiune imediată” și sugerează o alarmă. Inginerul se uită la datele brute: valoarea este „blocata” la un număr mare fix după un anumit timp, fără a se schimba niciodată. Aceasta nu este o vibrație crescută, ci este înghețarea/defecțiunea senzorului. Într-o defecțiune mecanică adevărată, valoarea fluctuează. Inginerul verifică senzorul; Conexiunea cablului este slabă. AI ​​a interpretat valoarea fixă ​​drept „bullish”. Lecție: excludeți semnăturile defecțiunilor (blocat, în afara intervalului, pulverizare) înainte de a interpreta datele senzorului; AI nu interogează datele brute.

Greșeli comune

  • Configurarea opririi de urgență cu contact FĂRĂ sau numai semnal software (nu este sigur).
  • Lăsând funcția de securitate exclusiv software-ului, fără un lanț hardware.
  • Crearea unei condiții de cursă cu linii de setare/resetare conflictuale.
  • Nu se definește o stare inițială sigură atunci când este alimentat.
  • Interpretarea datelor senzorului din calibrare și verificarea unității.
  • Semnale de eroare greșite (blocat, în afara intervalului) pentru măsurători reale.

Pe scurt

  • Împărțiți scenariul de automatizare într-o listă de I/O și clarificați pașii logici și întrebați AI astfel.
  • Funcțiile de oprire de urgență și de siguranță trebuie să fie de siguranță (NC), cu cea mai mare prioritate și înlănțuite hardware; verificate prin testare pe teren.
  • Misiunile conflictuale creează o condiție de cursă; Configurați procese complexe cu o mașină de stat.
  • Securitatea nu este lăsată niciodată numai software-ului; Aprobarea inginerului este obligatorie.
  • Calibrarea, unitatea și semnalele de eroare din senzorul/datele IoT sunt verificate mai întâi.
  • Valorile imposibile din punct de vedere fizic și citirile blocate sunt semne de funcționare defectuoasă, nu date reale.

Sarcina de aplicare

Scrieți o listă de I/O și pași logici pentru un scenariu simplu de automatizare (umplere, control porți, reglare nivel); Cereți AI pentru ST/scăriță. Apoi verificați logica generată: (1) Oprirea de urgență este sigură și prioritizată, (2) există o blocare pentru ieșirile aflate în conflict, (3) este definită pornirea sigură la pornire? Separat, cereți comentarii AI cu privire la o serie de citiri ale senzorului (mai multe valori normale, una blocată, una în afara intervalului) și verificați dacă elimină corect valorile de defecțiune. Corectați orice erori și scrieți-le.