Lecția 8.1 — Metodologia de diagnostic

Când o consolă ajunge pe masa de lucru cu simptomul nu pornește sau se oprește singură, un tehnician fără metodologie va înlocui componente la întâmplare, sperând să nimerească defectul. Un tehnician cu metodologie va urma un proces sistematic: reproduce problema, observă simptomele, formulează ipoteze, testează fiecare ipoteză cu instrumente, și izolează cauza reală înainte de a atinge ciocanul de lipit.

Această lecție acoperă pașii diagnosticului hardware — metodologia completă de la simptom la reparație — și analiza simptomelor — cum se interpretează indiciile pe care consola le oferă (LED-uri, sunete, comportamentul ventilatorului, mesaje de eroare) pentru a localiza defectul.

Scopul nu este memorarea unui checklist de diagnostic, ci înțelegerea de ce fiecare simptom are o cauză fizică, cum fiecare cauză poate fi verificată cu un instrument și de ce abordarea sistematică — nu intuiția — este fundația diagnosticului profesional.

8.1.1 — Definiția troubleshooting-ului

• Troubleshooting = formă de problem solving, aplicată la repararea produselor sau proceselor defecte
• Căutare logică și sistematică a sursei unei probleme pentru a o rezolva
• Necesar să identifice simptomele, să determine cauza cea mai probabilă, apoi să confirme soluția
• Procesul de eliminare (process of elimination) pentru excluderea sistematică a cauzelor potențiale
• O strategie = set organizat de activități exprimând o modalitate plauzibilă de a atinge un obiectiv
• Strategiile NU sunt algoritmi rigizi – rezolvatorii se adaptează oportunistic

8.1.2 — Diagnosticul – două tipuri de strategii

• Doi pași esențiali: cunoștințe de domeniu apriorice + strategii de căutare
• Strategia topografică: ghidată de funcționarea CORECTĂ a dispozitivului ("ce se întâmplă?")
• Deep reasoning, reasoning from first principles
• Necesită cunoaștere profundă/cauzală/model-based a sistemului
• Folosită la defecte noi (novel faults) când experiența nu ajunge
• Strategia simptomatică: ghidată de funcționarea ANORMALĂ ("ce e greșit?")
• Case-based reasoning sau shallow reasoning
• Bazată pe experiență anterioară – conexiuni stabilite între simptome și cauze
• Expertul cunoaște cauza pentru că a întâlnit cazuri similare
• CEA MAI PUTERNICĂ strategie, cea mai folosită
• NU funcționează independent cu probleme cu adevărat noi
• Cele două strategii se completează reciproc – simptomatica are nevoie de topografică și invers

8.1.3 — Aspecte fundamentale ale troubleshooting-ului

• Focus inițial: schimbări recente ale sistemului sau mediului
• PRINCIPIU: corelația NU implică cauzalitate (exemplu: dispozitiv defect după mutare)
• Necesită gândire critică (critical thinking), NU gândire magică (magical thinking)
• CELE TREI PRINCIPII FUNDAMENTALE:

1. Să poți REPRODUCE problema la cerere

2. Să reduci sistemul la cea mai simplă formă care încă prezintă problema

3. Să CUNOȘTI cum ar trebui să funcționeze sistemul (pentru a "observa" eroarea)

• Substituția serială: verificarea componentelor una câte una, înlocuind cu componente bune
• Considerată degenerată dacă se face fără ipoteză despre cum defectul produce simptomele
• Sistemele simple/intermediare: liste sau arbori de dependențe
• Sisteme complexe: dependențe ciclice, bucle de feedback – mai greu de biselat
• Repornirea (reboot) = pornire de la o stare cunoscută bună
• Troubleshooting poate fi organizat ca: checklist, procedură, flowchart, tabel
• Dezvoltate ÎNAINTE de apariția problemei pentru eficiență maximă

8.1.4 — Metoda Half-splitting (bisecția)

• Troubleshooting eficient: înțelegerea clară a comportamentului așteptat + simptomele observate
• Formularea ipotezelor → teste pentru eliminarea cauzelor → "divide and conquer"
• Două strategii comune:

1. Verifică ÎNTÂI condițiile frecvente sau ușor de testat ("milking the front panel")

Exemplu: verificarea LED-ului imprimantei, cablul bine conectat

2. "Bisecția" sistemului – verificare la jumătatea lanțului de dependențe

Exemplu: a ajuns job-ul la server? → problema e "spre utilizator" sau "spre dispozitiv"

• Half-splitting = aplicarea binary search pe dependențe serializate
• Similar jocului "20 de întrebări": 1 opțiune din 1 milion izolată în 20 de bisecții
• Eficient mai ales în sisteme cu lanțuri lungi de dependențe

8.1.5 — Reproducerea simptomelor

• Problemele reproductibile pot fi izolate și rezolvate în mod fiabil
• Efort considerabil se depune adesea pentru a găsi o procedură de reproducere

8.1.6 — Probleme intermitente

• Cele mai dificile probleme de troubleshooting
• În electronică: componente sensibile termic (rezistența variază cu temperatura)
• Aer comprimat pentru răcirea punctuală + pistol de căldură pentru încălzire
• Intermitent = "problemă pentru care nu există o procedură cunoscută de reproducere consistentă"
• Frecvența apariției ≠ procedura cunoscută de reproducere
• Uneori trebuie resort la metode statistice
• Testele de stres pot determina dacă componente specifice au cedat

8.1.7 — Probleme multiple

• Multe probleme apar din cauza defecțiunilor MULTIPLE
• Mai ales în sisteme fault-tolerant cu redundanță
• Substituția serială poate eșua cu defecte multiple
• Înlocuirea cu componente defecte poate CREȘTE numărul de probleme
• "Înlocuire" include și ajustare, reglare sau alte modificări
• Contactele murdare sau slăbite pot necesita doar curățare/strângere

8.1.8 — Definiția Root Cause Analysis (RCA)

• RCA = metodă de problem solving pentru identificarea cauzelor fundamentale ale defecțiunilor
• Folosită în: IT operations, manufacturing, telecom, industrial process control, accident analysis
• Combină abducția (generare ipoteze bazate pe dovezi empirice) și inferența deductivă (testare teorie)
• CEI 4 PAȘI AI RCA:

1. Identificarea și descrierea clară a problemei

2. Stabilirea unui timeline de la situația normală la apariția problemei

3. Distingerea între cauza fundamentală și alți factori cauzali (prin event correlation)

4. Stabilirea unui graf cauzal între cauza fundamentală și problemă

• Tehnici RCA (conform ISO/IEC 31010): Five Whys, FMEA, Fault Tree Analysis, Ishikawa diagrams, Pareto analysis

8.1.9 — Management reactiv vs proactiv

• Management REACTIV: reacție rapidă după apariția problemei, tratarea simptomelor
• Management PROACTIV: prevenirea problemelor
• Root cause = factorul a cărui eliminare PREVINE recurența problemei
• Factor cauzal = contribuie dar eliminarea sa nu previne recurența cu certitudine
• Exemplu clasic: mașina s-a oprit → siguranța arsă → suprasarcină → lubrifiant insuficient → pompă uzată → resturi metalice în pompă → cauza fundamentală = lipsa filtrului
• RCA servește ca input pentru procesul de remediere → acțiuni corective

8.1.10 — Principiile generale ale RCA

• Problem statement clar = "steaua polară" a RCA
• Adunarea factelor: declarații martori, cronologie, cerințe aplicabile
• Instrumente analitice: Pareto charts, process maps, fault trees, control charts
• Analiza apărărilor (Barrier Analysis): listarea apărărilor, căutarea dovezilor de eficacitate
• Întrebări focalizate, nebiased → linii de investigație
• Analiză cauză-efect: întrebări socratice până se epuizează răspunsurile
• ATENȚIE: Fishbone (1940s) și 5-Whys (1930s) nu sunt suficient de riguroase
• Acțiuni corective bazate pe Hierarchy of Hazard Controls
• Effectiveness review: evaluarea eficacității acțiunilor corective după implementare

8.1.11 — POST – definiție și funcționare

• POST = Power-On Self-Test, proces efectuat de firmware/software imediat după pornire
• Setează starea inițială a dispozitivului din firmware
• Detectează componente hardware nefuncționale
• Rezultatele: afișaj pe panel, output extern, sau stocate pentru diagnostic ulterior
• Eșecuri indicate prin: LED-uri intermitente sau coduri de bipuri (beep codes)
• Dacă POST reușește → se încarcă bootstrap loader → sistem de operare
• Responsabilități principale POST (IBM PC):

• Verificarea registrelor CPU

• Verificarea integrității codului BIOS

• Verificarea componentelor de bază: DMA, timer, interrupt controller

• Inițializarea, dimensionarea și verificarea memoriei principale

• Inițializarea BIOS

• Transferul controlului la extension BIOS (video, SCSI etc.)

• Identificarea și organizarea dispozitivelor de boot

• Versiuni BIOS ulterioare adaugă: inițializare chipset, descoperire și catalogare busuri și dispozitive, UI configurare, construirea mediului pentru OS

8.1.12 — Evoluția istorică a POST

• BIOS-urile inițiale: test complet de memorie la fiecare pornire (inspirat de mainframe-uri IBM)
• IBM PC original: 16 KB–640 KB RAM, 4.77 MHz 8088, POST: 5s–1.5 min, fără skip
• De la IBM XT: afișaj numărătoare memorie în loc de ecran gol
• PC-uri clone: posibilitatea de a sări testul RAM prin apăsarea unei taste
• Mașini moderne (2000+): adesea fără test RAM implicit (activabil din BIOS setup)
• DRAM modern semnificativ mai fiabil decât în anii 1980

8.1.13 — Coduri de eroare POST (beep codes)

• Original IBM: coduri numerice pe portul I/O 0x80, vizibile cu POST card sau logic analyzer
• Ulterior: secvențe de bipuri de la PC speaker
• Codurile variază între producători de BIOS și chiar între versiuni
• IBM original POST beep codes:

• 1 bip scurt = POST normal, sistem OK

• 2 bipuri scurte = eroare POST, cod pe ecran

• Fără bip = alimentare, system board, CPU deconectat

• Bip continuu = alimentare, system board, RAM sau tastatură

• 1 lung + 2 scurte = problemă display adapter

• AMI BIOS beep codes:

• 1 = Memory refresh timer error

• 2 = Parity error in base memory (primii 64 KiB)

• 3 = Base memory read/write test error

• 5 = Processor failure

• 8 = Display memory error

• Bipuri continue = niciun modul RAM detectat

• CompTIA A+ (examen):

• Bipuri scurte constante = alimentare defectă

• Ton lung continuu = defecțiune memorie

• Un lung + două scurte = defecțiune placă video

• IBM POST diagnostic codes (intervale numerice):

100-199 = System boards, 200-299 = Memory, 300-399 = Keyboard

400-499 = Monochrome display, 500-599 = Color/graphics display

1700-1799 = Hard drive/adapter

8.1.14 — POST pe alte platforme

• Macintosh (pre-1987): crash silențios + Sad Mac icon + string hexazecimal
• Macintosh (1987-1998): death chime (bip, crash mașină, geam spart, ton muzical)

+ Sad Mac icon + 2 string-uri hexazecimale

• New World Mac (1998+): 1 bip=no RAM, 2=RAM incompatibil, 3=nicio bancă OK, 4=ROM bad, 5=CPU bad
• Apple Silicon: fără coduri audio/vizuale la erori fatale hardware
• Amiga: secvențe de culori pe ecran în loc de bipuri

• Roșu = ROM bad, Galben = CPU exception, Verde = Chip RAM bad, Negru = no CPU

• LED tastatură: 1 flash=ROM, 2=RAM, 3=Watchdog, 4=scurtcircuit

8.1.15 — FDIR – Fault Detection, Isolation and Recovery

• Subdomeniu al ingineriei de control: monitorizarea unui sistem, identificarea defecțiunii, localizarea
• Două abordări: recunoaștere directă a pattern-urilor senzorilor și analiza discrepanței vs valori așteptate
• Defect detectat = când discrepanța (rezidualul) depășește un prag
• Izolarea defectului = categorizarea tipului și localizării defecțiunii
• Tehnici FDI bazate pe model: observer-based, parity-space, parameter identification
• Tehnici FDI bazate pe procesarea semnalelor: operații matematice/statistice, rețele neuronale
• Exemplu: TDR (Time Domain Reflectometry) – semnal trimis pe cablu, reflecție analizată
• Fault Recovery: acțiune după detectare și izolare

• Oprirea echipamentului defect

• Comutare la echipament redundant

• Trecerea sistemului într-un Safe Mode cu funcționalități limitate

8.1.16 — Diagnosticul defectelor în mașini

• Metode de colectare date: monitorizarea vibrațiilor, imaging termic, analiza particulelor din ulei
• Procesare: analiză spectrală, wavelets, Fourier transform
• Root cause failure analysis: identificarea cauzei originale (ex. rulment defect → aliniere greșită la montaj)
• Diagnosticul stării nu este suficient → trebuie identificată cauza fundamentală
• Strategii de mentenanță:

• Condition-based maintenance (pe baza stării)

• Planned preventive maintenance

• Preventive maintenance

• Corrective maintenance (fără diagnostic)

Metoda Half-splitting (bisecția)

• Half-splitting = aplicarea binary search pe dependențe serializate

POST – definiție și funcționare

• Verificarea registrelor CPU

POST pe alte platforme

• New World Mac (1998+): 1 bip=no RAM, 2=RAM incompatibil, 3=nicio bancă OK, 4=ROM bad, 5=CPU bad

• Roșu = ROM bad, Galben = CPU exception, Verde = Chip RAM bad, Negru = no CPU

În contextul consolelor de jocuri, metodologia de diagnostic joacă un rol esențial în funcționarea hardware-ului.

Componentele reale care utilizează pașii diagnosticului hardware se regăsesc în toate consolele moderne.

• Definiția troubleshooting-ului: Troubleshooting = formă de problem solving, aplicată la repararea produselor sau proceselor defecte
• Diagnosticul – două tipuri de strategii: Doi pași esențiali: cunoștințe de domeniu apriorice + strategii de căutare
• Aspecte fundamentale ale troubleshooting-ului: Focus inițial: schimbări recente ale sistemului sau mediului
• Metoda Half-splitting (bisecția): Troubleshooting eficient: înțelegerea clară a comportamentului așteptat + simptomele observate
• Reproducerea simptomelor: Problemele reproductibile pot fi izolate și rezolvate în mod fiabil
• Probleme intermitente: Cele mai dificile probleme de troubleshooting
• Probleme multiple: Multe probleme apar din cauza defecțiunilor MULTIPLE
• Definiția Root Cause Analysis (RCA): RCA = metodă de problem solving pentru identificarea cauzelor fundamentale ale defecțiunilor
• Management reactiv vs proactiv: Management REACTIV: reacție rapidă după apariția problemei, tratarea simptomelor
• Principiile generale ale RCA: Problem statement clar = "steaua polară" a RCA
• POST – definiție și funcționare: POST = Power-On Self-Test, proces efectuat de firmware/software imediat după pornire
• Evoluția istorică a POST: BIOS-urile inițiale: test complet de memorie la fiecare pornire (inspirat de mainframe-uri IBM)
• Coduri de eroare POST (beep codes): Original IBM: coduri numerice pe portul I/O 0x80, vizibile cu POST card sau logic analyzer
• POST pe alte platforme: Macintosh (pre-1987): crash silențios + Sad Mac icon + string hexazecimal
• FDIR – Fault Detection, Isolation and Recovery: Subdomeniu al ingineriei de control: monitorizarea unui sistem, identificarea defecțiunii, localizarea
• Diagnosticul defectelor în mașini: Metode de colectare date: monitorizarea vibrațiilor, imaging termic, analiza particulelor din ulei

Întrebarea 1

Care afirmație este corectă despre: Doi pași esențiali?

• a) ghidată de funcționarea ANORMALĂ ("ce e greșit?")
• b) cunoștințe de domeniu apriorice + strategii de căutare
• c) ghidată de funcționarea CORECTĂ a dispozitivului ("ce se întâmplă?")
• d) schimbări recente ale sistemului sau mediului

Întrebarea 2

Care afirmație este corectă despre: Focus inițial?

• a) ghidată de funcționarea CORECTĂ a dispozitivului ("ce se întâmplă?")
• b) schimbări recente ale sistemului sau mediului
• c) ghidată de funcționarea ANORMALĂ ("ce e greșit?")
• d) cunoștințe de domeniu apriorice + strategii de căutare

Întrebarea 3

Care afirmație este corectă despre: Troubleshooting eficient?

• a) înțelegerea clară a comportamentului așteptat + simptomele observate
• b) ghidată de funcționarea ANORMALĂ ("ce e greșit?")
• c) cunoștințe de domeniu apriorice + strategii de căutare
• d) ghidată de funcționarea CORECTĂ a dispozitivului ("ce se întâmplă?")

Întrebarea 4

Care afirmație este corectă despre: În electronică?

• a) ghidată de funcționarea CORECTĂ a dispozitivului ("ce se întâmplă?")
• b) cunoștințe de domeniu apriorice + strategii de căutare
• c) componente sensibile termic (rezistența variază cu temperatura)
• d) ghidată de funcționarea ANORMALĂ ("ce e greșit?")

Întrebarea 5

Care afirmație este corectă despre: Folosită în?

• a) ghidată de funcționarea CORECTĂ a dispozitivului ("ce se întâmplă?")
• b) ghidată de funcționarea ANORMALĂ ("ce e greșit?")
• c) IT operations, manufacturing, telecom, industrial process control, accident analysis
• d) cunoștințe de domeniu apriorice + strategii de căutare

🧠 Exercițiu: Metodologia de diagnostic

Scenariu: Analizezi un sistem hardware care utilizează conceptul de pașii diagnosticului hardware. Pe baza cunoștințelor din această lecție, răspunde la următoarele întrebări:

• 1. Defineste pe scurt: pașii diagnosticului hardware.
• 2. Ce rol are analiza simptomelor în contextul hardware-ului?
• 3. Cum se aplică această noțiune în ingineria consolelor?