Spetsifikatsioon on olemas ja on selge mida kliendil vaja on. Plaan on tehtud ja eelarve kokku lepitud. Nüüd tuleb tööle asuda ja disain valmis teha. See töö ei alga mitte skeemi alustamisest vaid tekstitööriista avamisega.
Inseneri töö on dokumentide loomine. Mitte ainult skeem, trükkplaadi gerberfailid, komponentide ladumisfailid ja komponentide nimekiri, vaid kogu väärtuslik teave mis arenduse käigus loodi. Klient maksab kogu sinu loodud teabe eest ja mis ei ole kirjas seda pole olemas. Mõjub märksa profesionaalsemalt, kui su töö on talletatud dokumendina. Sedasi informatsioon taasesitatav ja taaskasutatav – täna ja tulevikus.
Disainikirjeldus
Iga skeemiosa kohta tuleb luua disainikirjeldus. See on dokument, mis kirjeldab inseneri mõttekäiku ja kaalutlusi, arvutusi ja katseid, millele tuginedes ta skeemikomponendid valib. Millistel kaalutlustel valib skeemitehnilised lahendused.
Sellel dokumendil on mitu mõtet. Tähtsam neist on kirjutamise mõju insenerile endale. Pannes oma disainiga seotud mõtted paberile muutuvad need konkreetsemaks ja neid on lihtsam korrastada. Disaini elemendid saab ükshaaval läbi mõelda. See protsess teeb nähtavaks liigsed oletused millel puudub toetav tõendusmaterjal. Seega parandab disainikirjelduse kirjutamine disaini kvaliteeti ja vähendab oluliselt tõenäosust, et mõni oluline süsteemne viga sisse satub.
See dokument jääb ka tuleviku tarbeks. Kui projektist läheb veidi aega mööda, on tarvis mälutuge millele toetuda, kui tekib küsimusi mis kaalutlustel üks või teine disainivalik tehti. Haruldased ei ole juhtumid, kus seadet plaanitakse kasutada teisiti, kui esialgne disain ette nägi ja disainikirjeldusest võiks paista kas midagi dimensioneeriti igaks juhuks varuga.
Mäletan ühte tarkvara arendusega seotud põhimõtet. Sa võid kirjutada kõige ägedamat koodi maailmas, aga see on ikka halb, kui vaid sina seda lugeda oskad. Põhjus on selles, et aja möödudes vajab su kood täiendust, uusi funktsioone või turvaaukude paikamist. Kui järgmine insener peab sinu töö sisuliselt uuesti tegema on sinu töö panuse väärtus selle võrra väiksem.
Sama lugu on elektroonikas. Disainitud elektroonikakoostu eluiga alles algab selle momendiga, kui disainiprotsess lõppeb ja tootmine algab. Esimene seeriatootmise partii ei ole tõenäoliselt selle koostu ainus. Toodet, mille osa see koost on, tahetakse toota võibolla viis, aga võibolla ka viisteist aastat. Selle aja jooksul tekib mitmeid põhjuseid, kus keegi peale disaineri, peab aru saama mõne skeemiosa toimimisest. Asjad nagu eluea lõppu jõudnud komponendid, komponentide kvaliteediprobleemid, komponentide tarneraskused, tootmistestrite testilimiitide ülevaatus on elektroonikakoostude tootmise juures igapäevased. Seda kutsutakse toote eluea halduseks. Ja see on väga keeruline teha, kui ainus millele asjaga tegelev insener toetuda saab on skeem üksi.
Mõistlik on kirjutada disainikirjeldus igale alamskeemile eraldi dokumenti. See annab võimaluse iga skeemiosa loomine eraldi alamülesandeks teha ja hoiab dokumendi pikkuse mõistlikuna.
Disainikirjelduse esimene osa peaks olema disainiülesande kirjeldus. Mis on see funktsioon, mida skeem täitma peab ja millistele nõuetele peab see vastama. Kui palju voolu? Milline rikkekindlus? Millised piirangud pindalale? Millised on temperatuurinõuded ja ootused süsteemi hinnale? Kõik see tuleb sissejuhatuseks kirja panna. See aitab disaineril endal veenduda, et nõuded oleksid silma all ja saaksid täidetud. Samuti info tulevikuks, kui keegi peab disainimuudatusi tegema ja veenduma, et uus süsteem oleks vähemalt samaväärne. Sellises olukorras on oluline teada mida silmas pidades skeem esialgselt loodi.
Disaini teine osa peaks olema skeemi kirjeldus. Põhjendatakse skeemi ja komponentide valikut. Näidatakse asjasse puutuvaid arvutusi ja seletatakse milliseid oletusi tehakse. Tekst peab olema soravalt loetav ja mitte lihtsalt üksteisele järgnev rida arvutusi.
Disainikirjelduse kolmas osa võib olla simulatsioonis või prototüübil tehtud katse raport. Katseline tõestus ei pruugi iga kord asjakohane olla. Näiteks on käimas esimese prototüübi arendus ja see esimene prototüüp pakubki katselise tõestuse. Aga kui simulatsioonide või prototüüpide tegemine käsile võtta, annaks see veendumust, et disainer on kokku pannud midagi toimivat.
Skeem
Skeemi esimene ülesanne on kommunikeerida komponentide vahelisi ühendusi teistele inseneridele. Tundub väga ilmne, aga olen näinud liiga palju skeeme, mille ülesanne näib olevat komponendi väljaviikude ühendamine joonekestega selleks, et CAD tööriist PCB-l õiged ühendused teeks. Mõtlen sellega seda, et skeemi loetavusele ei ole grammigi tähelepanu pööratud.
Et skeem peab olema loetav tuleneb jälle sellest, et toode vajab tuge pikema aja vältel ja mitme inseneri poolt. Loetavus on ilmselt mitmetähenduslik ja sõltub esteetika meelest. Või nagu üks lugupidamist vääriv vanem kolleeg ütles – peakujust. Aga mõned põhimõtted on üldised.
Funktsionaalselt eraldiseisvad alamskeemid peaksid olema eraldi skeemilehtedel. Seda muidugi juhul, kui skeem muidu ühele A3 või A4 mõõdus lehele ära ei mahu. Ning kui alamskeemi on võimalik omakorda jagada väiksemateks loogililisteks skeemikesteks, tasub need samuti ühe lehe raames visuaalselt eristada. Skeemiosade vahelisi ühendusi tähistatakse võrgunimede või globaalsete portidega. Enamustel juhtudel huvitab inseneri alamsüsteemi juures vahetult seda alamsüsteemi puudutavad osad ning oluline oleks neid hoida lähestiku ja ühendused süsteemide vahel võimalikult lihtsalt tähistada.
Näide allpool
Igal skeemilehel peaksid olema unikaalne prefix komponendi tunnusele. Näiteks esimesel skeemilehel on takistid R100, R101. Teisel lehel R200, R201 jne. See aitab veaotsijatel ja teistel elektroonikakoostuga töötavatel inimestel kiiresti leida skeemis see komponent, mis neile trükkplaadil huvi pakub.
Kindlasti oleks viisakas iga skeemiosa juurde teha viide vastavale disainikirjeldusele. See säästab jälle nende spetsialistide aega, kes tulevikus skeemi uurima peavad. Nad ei pea aega kulutama mõistatamisele millises dokumendis skeemi toimimist puudutav informatsioon paikneb või kas mingeid küsimusi, mis tema nüüd küsib, disaini käigus üldse küsiti.
Ja viimaks üks retronõue – kirjanurk. See ütleb, mis on toote nimi ja versioon mille kohta skeem käib. Ütleb kes on skeemi autor, mis kuupäeval see valmis ja millide disainibüroo või ettevõte selle toote lõi. Tundub vanamoeline ja meenutab möödunud sajandi käsitsi joonestamise aegu. Aga teistes organisatsioonides töötravatel inseneridel ei pruugi olla ligipääsu sinu disainitarkvarale ja üsna kindlasti ei ole neil ligipääsu sinu disainiprojektile. Üsna suure tõenäosusega on neil kasutada vaid pdf formaadis skeemi väljatrükk ja see väljatrükk peab üheselt ütlema millise toote kohta see kehtib.
Skeemi ülevaatus
Loodud disaini kvaliteeti aitab tagada skeemi ülevaatus. See on protsess, kus keegi peale disainiinseneri enda skeemi läbi analüüsib ja veendub disaini kvaliteedis. See ei ole garantii, et kõik on hästi. Pigem vähendab tõenäosust, et asjad on halvasti viisil, mida kumbki ette ei näinud.
Et skeemi ülevaatus oleks edukas peab disainikirjeldus olema ammendav. Vastasel juhul peaks ülvaatust tegev insener ennast kurssi viima skeemile kehtivate ootuste ja nõuetega, iseseisvalt läbi töötama kõik skeemi komponendid ning aru saama miks need valitud viisil kokku on ühendatud. See võtaks ebamõistlikult kaua aega. See oleks sisuliselt disaini uuesti tegemine. Mistõttu praktikas jääb skeemi ülevaatus ilma disainikirjelduseta pealiskaudseks ja tegelema trükivigadega.
Disainikirjeldus aga annab ülevaatust tegevale insenerile kogu vajaliku tausta. See seletab miks tehti üks või teine skeemitehniline valik, esitab arvutuslikud tõendid ja selgitab komponentide valiku aluseid. Kogu raske töö on sellega tehtud. Ülevaatust tegev insener on sellises olukorras nagu keegi lõputöö kaitsmise komisjonis. Ta kulutab disainile ja selle dokumendile paar tundi, kuid saab tervikpildi eesmärgist, lahendusest ja tõendusest. Ning sellelt tasemelt alustades on realistlik, et silma torkab mõni tõsine loogikaviga, tähelepanematus või arvestamata jätmine.
Ja siis dokument. Antud juhul on selleks skeemi ülevaatuse raport. Selle dokumendiga kommunikeerib ülevaatust tegev insener oma mõtted ja kommentaarid tagasi disainiinsenerile. Selle dokumendiga vormista ülevaatust tegev insener oma töö. Sest mida pole kirjas seda pole tehtud.
Skeemi ülevaatusest võivad tulla täpsustavad küsimused, tähelepanu juhtimised ja soovitused. Aga need ei võta vastutust disainiinsenerilt kelle töö on teha lõplik otsus milliseid nõuandeid järgida ja milliseid riske võtta.
Trükkplaadi kujundus ja trükkplaadi ülevaatus
Trükkplaadi kujunduse kohta mul dokumente puudutavaid nõuandeid ei ole. Selles osas elektrooniku töös on nõuanded vaid tehnilist laadi ja see ei ole selle artikli teema. Gerberfailid vastavad levinud standardile. Kõik tööriistad oskavad neid standardile vastavalt tekitada ja küllap trükkplaadi tootja kaebab, kui miski ei toimi.
Trükkplaadi ülevaatuseks soovitan luua kontrollnimekirjaga standardmalli. Seal võivad olla asjad tüüpiliste elektromagneetiliste ühilduvuste probleemide põhjuste vältimiseks. Toodetavuse küsimused näiteks fiducialite olemasolu või vaba ruum selektiivselt lainejoodetavate komponentide ümber. Küsimus selle kohta, kas trükkplaadi koostu 3D mudel on kooskõlastatud mehaanikainseneridega jne. Seda nimekirja on kõige parem tekitada koos selle meeskonnaga, kellega sa koos töötad.
Kokkuvõtteks
See artiklite kollektsioon ilmselt on märk sellest, et mulle meeldib kirjutamine märksa rohkem, kui keskmisele insenerile. Minu aju registreerib töö lõpu alles siis, kui minu tehtud arendustöö tulemused on talletatud dokumendis teistele spetsialistidele lugemiseks. Võibolla ei ole see niivõrd tavaline ja selle täiendava kirjutamistöö tulemus lühikeses plaanis tuntav. Aga pikas plaanis siiski.
Mul on kogemust kümme ja rohkem aastat vanade elektroonikadisainide toetamisega tööstuse kontekstis. Ma olen varem rääkinud elektroonikamoodulist, mis oli nii edukas ja universaalne, et oli seeriatootmises ka 18 aastat pärast disaini loomist. Minu töö oli sellel pingeregulaatori induktori asendamine. Muidu sirgjooneline ülesanne, aga kohutavalt aeganõudev. Sest ei leidunud ühtegi dokumenti, mis selgitaks, mille alusel eelmine induktor valiti või millist sooritust regulaatorilt vaja oli. Küsimus siis mille alusel ma teen asenduskomponendi valiku ja mille alusel valin verifikatsioonitestide limiidid?
Usu, et ka sinu disain elab aastaid. Klient on sellele kulutanud sadu, kui mitte tuhandeid inseneritunde. Ta tahab seda toota nii kaua, kui võimalik – tõenäoliselt kauem kui sina asjaga seotud oled. Seega käitu nagu hea isa ja anna oma disainidele dokumentatsiooni näol kaasa parimad võimalused edukaks elukaareks.