80°C — temperatura, przy której kończy się PowerPoint, a zaczyna produkt

80°C to nie musi być awaria. To temperatura rdzenia CPU, przy której wiele platform embedded przestaje zachowywać się tak jak w demo. Procesor ścina taktowanie, żeby się nie spalić. Model gubi klatki. Retry loop nagrzewa płytę. System dalej “działa”, tylko wolniej, mniej stabilnie i w sposób, którego nikt formalnie nie przetestował.

Na slajdach wszystko wygląda gotowo. Sprzedaż ma datę. Zarząd ma oczekiwanie. Klient ma obietnicę.

A potem przychodzi field.

I field nie testuje funkcji. Testuje cały łańcuch decyzji, który do tej funkcji doprowadził: zasilanie, montaż, termikę, workload, support.

Produkt HW+SW nie jest gotowy, kiedy przechodzi demo. Jest gotowy, kiedy przechodzi warunki, których klient nie będzie umiał ani chciał debugować.

Teren to nie stres-test — to normalność

Różnica między laboratorium a terenem jest prozaiczna, a firmy wciąż na niej tracą:

• Temperatura: nie 22°C biuro, tylko 38°C hala produkcyjna albo -5°C u klienta
• Montaż: nie precyzyjny stojak testowy, tylko listwa pod sufitem z przypadkowym kablem
• Zasilacz: nie zatwierdzony przez R&D, tylko “ten co był”
• Workload: nie 5-minutowy scenariusz demo, tylko 8 godzin ciągłej pracy bez restartu

Żaden z tych warunków nie jest zaskoczeniem. Każdy wiadomy od pierwszego dnia projektu. Problem nie polega na tym, że nie dało się ich przewidzieć. Polega na tym, że nikt nie miał ownershipu, żeby zamienić je w bramkę decyzyjną. R&D patrzy na swój fragment, procurement na swój, compliance na swój, sprzedaż na termin. Lukę między nimi, czyli moment, w którym demo ma stać się produktem w terenie, rzadko ktoś bierze na siebie.

Cztery miejsca, w których HW+SW psuje się po cichu

W czystym software bug siedzi w kodzie. W HW+SW bug bywa interakcją fizyki z logiką, więc trudniej go znaleźć: objaw pojawia się daleko od przyczyny. Cztery typowe, ułożone od najbardziej widocznego do najgłębiej zakopanego.

CPU throttluje, produkt zwalnia. Urządzenie przetwarza obraz albo dane w czasie rzeczywistym. W wysokiej temperaturze procesor ścina taktowanie, żeby zejść z temperatury. Model zaczyna gubić klatki albo spóźniać się z odpowiedzią. Support szuka błędu w oprogramowaniu, a problem jest w temperaturze. Log nie mówi “throttling”. Mówi “slow response”.

Firmware retry loop grzeje układ. Błąd komunikacji generuje pętlę: próba, timeout, retry, i tak setki razy na minutę. W normalnych warunkach niewidoczna, bo za rzadka. W cieple dokłada kolejne stopnie na płycie i uruchamia ten sam throttling co wyżej. Korelację widać dopiero po zestawieniu logów komunikacyjnych z temperaturą.

Obudowa premium, thermal path żaden. Estetyczny design, IP65, świetne zdjęcia do folderu. Przy IP65 obudowa jest szczelna z założenia, więc powietrza nie przewietrzysz — ciepło musi wyjść inaczej: przewodzeniem, padem termicznym, masą obudowy, radiatorem dobranym do realnego obciążenia. Jeśli industrial design zatwierdzono bez thermal review, tej ścieżki zwykle po prostu nie ma. Problem nie w szczelności, tylko w braku zaprojektowanego odprowadzania ciepła. Kto i na jakim etapie miał ten gate postawić? PM.

Zasilacz z etykietą, nie ze specyfikacją systemu. Na stronie dostawcy: 12V 5A, ripple 120 mV. Wymaganie systemowe: 50 mV. Ten sam numer katalogowy, faktycznie inny producent. Zasilacz spełnia specyfikację komponentu, ale nie specyfikację systemu. To różnica, którą PM musi rozumieć: datasheet komponentu to nie to samo co wymaganie systemowe.

Jedno pytanie — i co zrobić z odpowiedzią

PM nie musi projektować radiatora. Musi wiedzieć, w którym momencie jego brak stanie się problemem klienta, supportu i marży. A do tego wystarczy jedno pytanie:

“Gdzie jest raport testu tego urządzenia: zamkniętego, w docelowym montażu, na finalnym zasilaczu, przy pełnym workloadzie, przez 72 godziny w maksymalnej temperaturze otoczenia ze specyfikacji produktu?”

Brak testu środowiskowego to nie oszczędność czasu. To przeniesienie kosztu z R&D na support, klienta i Twoją reputację. “Sanity check 72h” nie jest pełną walidacją środowiskową. To minimum, które przesuwa ryzyko ze sfery “nie wiemy” do sfery “wiemy co może pójść nie tak i mamy plan”.

Zasilacz, który kosztował 6 miesięcy

Firma chciała zmienić zasilacz impulsowy w jednym ze swoich urządzeń, sterowniku PLC. Powód prozaiczny: stary model schodził z produkcji. Tyle że zmiana dotykała naraz spare parts dla setek istniejących instalacji i nowych urządzeń wchodzących do produkcji. To nie był problem zakupowy. To był problem ciągłości biznesu.

Zamiennik był dostępny. Ale w międzyczasie zmieniły się przepisy, a jego certyfikaty wymuszały inną klasę niepalności. Żeby ją osiągnąć, trzeba było podnieść ochronę przeciwpożarową całego sterownika: niepalne okablowanie w środku, dodatkowe zabezpieczenia i destrukcyjny test jednego egzemplarza — spalenie sterownika, żeby zobaczyć, jak zachowa się w razie pożaru. Na dokładkę nowy zasilacz grzał się za mocno.

Od wykrycia problemu do decyzji co z nim zrobić minęło 6 miesięcy. Spare parts utknęły, nowe urządzenia czekały na zatwierdzony BOM, a zespół chodził w kółko między dostawcą, compliance i procurement.

Lesson learned: zmiana jednego komponentu w certyfikowanym urządzeniu to nie swap. To otwarcie całego łańcucha: certyfikacja, okablowanie, termika, supply chain i reszta technicznych zależności. Im wcześniej je znasz, tym tańsze są opcje.

Bramka decyzyjna — zanim produkt wyjdzie na rynek

Nazywam ją Field Readiness Gate: jedna bramka decyzyjna między “działa w demo” a “jedzie do klienta”. To nie pełna walidacja środowiskowa, tylko minimum, które ktoś musi wziąć na siebie, zanim urządzenie trafi w teren.

Środowisko i design

• Testy środowiskowe zgodne z wymaganiami dla danego typu produktu — albo potwierdzenie w dokumentacji, że komponenty w środku spełniają wszystkie wymogi i na tej podstawie produkt można zatwierdzić
• PoC u finalnego klienta — w lokalizacji testowej albo laboratorium najbliższym realnemu obciążeniu u klienta końcowego
• Docelowy montaż: orientacja, mocowanie, odległości od ścian i innych urządzeń

Obciążenie

• Pełny workload operacyjny, zdefiniowany konkretnie: co działa, jakie procesy, jaka intensywność
• Retry behavior: co dzieje się przy błędach komunikacji pod obciążeniem i w wysokiej temperaturze jednocześnie

Monitoring

• System loguje temperaturę CPU, throttling state, napięcia, restarty, błędy komunikacji
• Próg alertu przed throttlingiem, z akcją po przekroczeniu, nie tylko powiadomieniem
• Wiadomo, jakie dane zebrać przy zgłoszeniu “działa wolniej” albo “zawiesza się”

Decyzja

• Kto ma raport z testu? Kto zaakceptował odchylenia? Jakie są warunki ograniczające pilota?

---

Twój produkt ma ruszyć do klienta za 6 tygodni. Zadaj jedno pytanie: czy istnieje raport testu w docelowych warunkach instalacji, w maksymalnej temperaturze otoczenia ze specyfikacji?

Jeśli istnieje, masz podstawę do decyzji. Jeśli nie, nie masz jeszcze produktu gotowego do fieldu. Masz demo z datą sprzedaży.

Wtedy są trzy uczciwe opcje: opóźnić release, ograniczyć pilot do kontrolowanych warunków z monitoringiem, albo świadomie zaakceptować ryzyko i zapisać, kto tę decyzję podjął.

Najgorsza opcja to udawać, że brak danych oznacza brak problemu. W HW+SW ryzyko nie znika. Czeka, aż znajdzie je klient.

---

Jeśli Twój produkt zbliża się do pilota, a nie masz pewności, czy przejdzie warunki z terenu, sprawdźmy to zanim zrobi to klient.

Zobacz, jak mogę pomóc →