Miluji hardwerare, kteri maji utkvelou predstavu jak je vyvoj software jednoduchy. Delal ten pan nekdy na velkych datovych kolekcich, kde se na vysledek ceka mnohdy dny, kdy zmeny v distribuovane aplikaci vyplynou az po nekolika tydnech ostreho provozu, ma vubec predstavu jak se v takovem prostredi cokoliv ladi, protoze se to jen velmi obtizne "simuluje" a znovu opakuje? Trosku pokory mili harwerari, ne vsichni softwerari delaji tuctove business aplikace a frikulinske UX aplikace pro mobily - to jsou jen vase mylne predstavy.
kolega mi vypravel jak pracoval u jednho prodejce HW a mel na otestovani novy server a ten se pravidelne kazdej den kolem pulnoci (avsak ne vzde v presne stejny cas) vypnul a po chvili zase zapnul hledali chybu nic nenasel, dalsi den nainstaloval ruzne analiticke nastroje a zase kolem pulnoci se zase server odlmcel, vyzkousel vse mozne a na nic neprisel proc se to deje no rika si ze bude muset noc stravit v praci a fyzicky zkontolovat co se s tim servrem deje kratce po pulnoci prisla uklizecka vytahla server ze site a pichla si tam vysavac zahada byla vyresena :D
Tak jsem si připomněl, jak jsme kdysi instalovali u zákazníka vylepšenou elektroniku (od externího dodavatele) na naše zařízení. Elektronika běhala, já jsem se u toho nudil, tak jsem prstem stisknul koncový spínač v poloze, kde se nepředpokládalo, že by se sepnul. Elektronika se kousla a do provozního stavu ji bylo nutno uvést jen vypnutím a novým zapnutím. Tak se přišlo na to, že ve FW tenhle stav (co by výjimečně nastat mohl) zapomněli ošetřit.
Neviděl bych to tak tragicky, je společenská (komerční) poptávka na IoT články. Tak se generují. To, že různé technologie tady máme dlouho, ceny jsou příznivé, mobilní telefony široce dostupné a mnohdy std. užívané i předškolními dětmi. Prostě vede k rozvoji tohoto trhu. Klasická robustní odolná řešení s dlouhým životním cyklem však pro tento spotřebitelský segment nevyhovují. Logicky tedy vznikají různá nedokonalá cool řešení s praktickou životností 1- 2 let. Bohužel nás dotčené jinou oblastí to irituje, neboť v mnoha věcech máme osobní zkušenost a víme, že s produktem o životním cyklu >5 let nedej bože >10 let, je ta problematika úplně někde jinde. Pro ty co budou tvrdit, že to není problém vyměnit po těch 2 letech, tak ne vždy je to možné nebo náklady (finančně/časové) na takovou výměnu jsou výrazně větší než cena takového řešení.
Relativně těsně po revoluci si v jedné firmě koupili HP9000 byla tam i UPS, stále ji záhadně padala. Nakonec tam zapojili zapisovač (na termopapír) napětí. A ejhle výsledek pátrání byl jednoduchý. Přesně to sedělo na čas regulace jalového výkonu jejich energetikou ve výrobě. :-) Taky supr.
Radsi brzdete vy, protoze ja znam obe skupiny, ktere se snazite porovnavat, a navic jsem ve svem veku uz pomerne objektivni divak. Argumentujete kuprikladu bezpecnostnimi testy - kolik to stoji (cash+time) v pripade software s overovanim podle vyssich EALu?
Vase (a podobne) argumenty slycham casto od hardweraru, kteri pouzivaji maximalne tak VisualBasic na rekalkulace fyzikalnich/elektro vzorecku, v C s obtizemi napisou jednovlaknou vec o par tisicich radek pro nejaky PIC, mozna dokazou ubootovat predpripraveny Linux, a v CADu si nakresli tistak. S touhle urovni se pousti do filosofovani o narocnosti tvorby hardware a srovnavaji to se svymi schopnostmi v programovani - presneji - s tim, co si mysli, ze programovani je. Mne to prijde detinske, protoze oba obory jsou na sve spickove urovni intelektualne i financne nesmirne narocne... kdo umi, ten umi, kdo neumi, tak proste vyviji draze anebo produkuje nekvalitni veci.
ID karty radsi komentovat nebudu, tam hardwerari napachali za ty roky neskutecne bezpecnostni boty prave tim, jak "kvalitne" pracuji. Na druhou stranu, chipy na hrane fyzikalnich moznosti jsou skutecne maly zazrak. Podobna srovnani by se nasla i u software.
Zákazník chce, zákazník má. Protokoly/standardy jsme nevyvijeli. Věř že raději bychom implementovali jen magnet/cip. To bylo mnohem méně bolestive. To co jsem zmiňoval byl vývoj platebního terminálu. Nemůžete použít na čtení běžné čipy. Třeba magnetická hlava už sama než to pošle po dratech tak sifruje. Stejně tak část co čte rfid tak už to po sběrnici leze tím čipem zasifrovane. Je to zuzo to ladit. Nebo trošku vám predelaji desku a změní se vám tvar vyzařování pole rfid čtení což v lokálním labu těžko odhalíte. Smůla. Neprošlo certifikaci... Používáte maloobjemove cipy certifikovatelne PCI a jen desítky lidí na světě s nimi mají zkušenosti ( terminály jsou maloobjemove zboží narozdil třeba od mobilu). A co se týče sw. Věci jako časování po taktech a synchronizace s ostatními komponentami sběrnici, řízení spotřeby běžný SW patlal neřeší. Progros možná kdysi tušil co dělají věci v počítači, ale je od toho dost odstinen takze nemá představy a přímé vazby svého kódu na hw. Nejvíc hardcore co teď dělají naší vývojáři je prototypovani na FPGA pro jeden asic který půjde do výroby za 2 roky. Právě na čtení těch RFID karet s podporou sifrovani.
I dělali. Ale pořád testování třeba takového ZFS na farmách serveru před jeho releasem bylo řádově levnější než opraveni 20ti revizi vzorků/prototypu 100 výrobků každý v ceně 1500 euro. Nové pcb,nove čipy, nové bugy a neopravis to prostě jen tím ze pockas pár dní a predelas kód. Takže brzdi. Kolik myslíš že stojí pronajati uzavřené komory na em testy (potřebovali jsme certifikovat RFID čtení z visa karet)? Kolik myslíš že tě stojí bezpecnostni testy kdy se prototypy rizene rozflakaji?
Děláme zákazníky kteří mají I velké farmy na simulace třeba pohybu oblaku nebo burzovní systémy jako Xetra. Pořád je to levnější než řešit HW vývoj.
Někdy resis problém I měsíce než ti to zákazník akceptuje a debugujes teploty infrakamerou a spektralnim analyzatorem přímo u zakaznika zakaznika jaderné elektrárně.
Míchá se tady několik věcí dohromady.
Testování, jak o něm psal Malý, typu "1000x zmáčknu tlačítko", je opravdu triviální. Pokud netestuju mechanickou životnost tlačítka, stačí paralelně k němu hodit tranzistor a krmit ho třeba z jednočipu z vývojovýho kitu. Akorát na test HW není potřeba to tlačítko mačkat 1000x, stačí zkontrolovat na osciloskopu zákmity, napěťový úrovně, rychlost náběhu a doběhu.
Tam, kde je potřeba 1000x zmáčknout tlačítko, to je zase test firmware. A i tam se dá vše dělat jednoduše - vytáhnu z šuflete nějaký nepoužívaný kit, naprogramuju dálku a frekvenci impulsů na nějakým pinu, tranzistor paralelně k tlačítku a nazdar. Triviální věc.
Testování "na zkušebně" je drahý, náročný na vybavení (bezodrazová komora, klimatická komora, vibrační testy, ESD pistole,...). Ale tam není náročný to otestovat, náročný je to správně navrhnout. Chce to zkušenosti a pokud chybí, je sebelepší myšlenka na odpis. "Mladý a dynamický kolektiv" je v tomhle sebevražda.
Však jsem posledně psal, že vyhláška 50/1978 je prkotina ve srovnáním s ES Prohlášením o shodě... A bylo za to mínusů jak maku.
Ne že byste neměl pravdu, ale uznejte, že představy a výroky některých softwarových vývojářů o vývoji hw jsou úplně stejně nesmyslné a hloupé. On typický vývojář například podnikových informačních systémů (ať vynecháme extrémy v podobě bastličů webů na straně jedné a vývojářů software pro velké clustery na straně druhé) ví o vývoji hardware ještě méně, než ten hardwarář o vývoji běžného software.
Zkontrolovat instalaci,kompenzaci uciniku a trafostanici pokud je v majetku firmy - většinou s tím mají potíž fabriky. Objednat si analýzu napájení ocejchovanym přístrojem. Je to levnější než pořád měnit zelezo. Často potíže ani nezpůsobuje dodavatel elektřiny jako elektrická trakce podél vedení(tramvaje/vlaky/trolejbusy) nebo tovární stroje.
Za pokus to stojí. Minimálně to treba ČEZ/EON potají opraví jak mají v zvyku po podání reklamace. Je ti levnější než nahrazovat odpalene spotřebiče. ERU nedělá nic.
No a pak tu máme spotřebiče kterým vadí I česká HDO signalizace:-D
Tahle historka koluje v různých obměnách v mnoha firmách. Ale neobviňuji vás ze šíření urban legends, u nás se to taky stalo. Jen ne se samotným serverem, ale s externím storage boxem, kde byl umístěný mimo jiné i systémový disk. Jenže to bylo ještě v dobách operačních systémů, které se s tím dokázaly vyrovnat, takže my jsme si jen lámali hlavu nad tím, proč v logu skáčou tisíce chyb a ráno server i aplikace běží spokojeně dál.
Osobne znam minimalne dve firmy, kde maji vsude vyhradne online UPS, protoze napeti v siti kolisa setrvale a neustale tak nehoraznym zpusobem, ze zadne jine reseni nepomaha. Bez tech UPS HW v ruznych intervalech z "neznamych" pricin bud vytuhl uplne, pripadne SW zustaval ve vsemonych nedefinovanych stavech.
Spíš je to takový náš objevitel, který na všechno kouká jak žaba z křa a musí se o to rychle podělit, jinak by neusnul :D Novej kit, bum to na web. Novej pokus o síť pro IoT, hurá nadšeně na web. Uvidí 10 let starou technologii, užasne a hurá s tím na web jako s úžasným průlomem.
Schválně, co udělá, až zjistí, že existuje nějaký produkční test ve fabrice? A - kupodivu - automatizovaný a s logováním výsledků někam do databáze a server a evidencí podle sériových čísel? Tipl bych, že bude slintat jak slimák...
My sme takto prišli o batériu v HP SmartRAID v Proliante a jeden jeho kanál so 4 ks SCSI diskov, k tomu 4ks Odroidov XU4, ktoré slúžili ako X-terminály k tomu Proliantu. Pri dvoch nám neuynali reklamáciu,
Holt na vstupe je ručičkový voltmeter (filter kmitov) a aj na ňom je vidno kmitanie efektívnej hodnoty napájacieho napätia- tá ručička kmitá 24 hod. denne.
Ono testování HW zase tak náročný není. Nám na karty stačilo postavit mlýn z Merkuru, pohánět ho motorkem z walkmanu a jako čítač univerzální sada magnet-jazýčkový kontakt-kalkulačka...
Btw., největší problém testování není mačkat tlačítko. Největší problém je analyzovat, co přesně se tam děje. Hodiny koukání do logů...
A některý testy trvají pekelně dlouho, nejdelší, co jsem dělal, byl na 50 dní (ideální je to logovat na stroji s Windows, co se kvůli tomu za tu dobu 2x restartuje kvůli aktualizacím, co nejdou zakázat.)