Produktutvikling: Fra krav til krets

Vi har i denne artikkelen fått senioringeniør Ole Martin Grøtterød Vister fra Inventas til å ta oss gjennom noen grunnleggende faser av produktutviklingen, fra hvordan en kravspesifikasjon er bygd opp, til hvordan ulike valg i utviklingsprosessen bruker den for å begrunne valg som blir tatt.

Identifiser egenskaper

Dersom du skal utvikle et produkt, har du nok allerede klart for deg hva dette produktet skal gjøre og hvem som skal bruke det. Den neste oppgaven vil da være å identifisere hvilke egenskaper produktet må ha for å kunne få til dette. Ved å liste opp disse egenskapene vil du ha starten på en kravspesifikasjon som produktet skal designes etter.

Hvorfor sette opp krav

Disse kravene er litt som ingredienslista til et bakverk du skal lage. Du må ha dem, og dersom du mangler noen, vil ikke produktet funke slik som du kanskje hadde tenkt. Det er fordi at selv om du har en visjon for produktet ditt, kan det være at vi som ingeniører og designere oppfatter denne visjonen på en litt annen måte enn det du ville.

Kravspesifikasjonen må være på plass før du går i gang med selve utviklingen, ettersom den danner grunnlaget for alle beslutninger som tas senere i prosessen. Husk også å sjekke hva som trengs av dokumentasjon, godkjenninger eller sertifiseringer i det markedet du sikter på.

Kravspesifikasjonen

For å lage en god kravspesifikasjon kan det være greit å ha noen stikkord i bakhodet; entydig, testbar, presis, forståelig og realistisk. Entydig, siden det kun skal være én måte å tolke kravet på. Testbar, siden vi skal kunne verifisere at produktet lever opp til forventningene. Presis i den forstand at det ikke skal være noe info som ikke er relevant. Forståelig slik at det er grammatisk korrekt. Her er det greit å få med at ordet SKAL er bedre enn KAN, MÅ og KANSKJE. Realistisk med tanke på tid, penger og tilgjengelige ressurser og om hvorvidt det fysisk lar seg gjøre.

Komplette og konsistente

I tillegg burde et sett med krav være konsistente slik at det ikke er konflikter innad i et sett. De bør være komplette slik at produktet er bedre sikret til å kunne operere i hjørnetilfeller av tenkt bruksområde. De bør heller ikke være overflødige da alle kravene skal være spesifisert én gang og ikke dekke over hverandre.

Et eksempel på et dårlig og et godt krav kan se slik ut:

Dårlig: Produktet kan kobles til veggen for strøm. Bra: Produktet skal kunne kobles til 220V 50Hz Europeisk vegguttak gjennom en Europlugg av typen CEE 7/16.

Komponenter

Etter at kravteksten er blitt skrevet, og at du som kunde har tro på at vi som utviklere har forstått hva du mener, starter utviklingsprosessen. Da skal vi identifisere hvilke komponenter vi trenger for å løse kravene som er beskrevet i kravteksten. Den vil da spille direkte inn på valg av prosessor, hvilke sensorer og hvilke knapper og indikatorer som trengs. Vi må også ta stilling til om vi skal lage et skreddersydd design, eller om vi skal finne ulike eksisterende elektronikkmoduler som passer til kravene og koble dem sammen.

Hyllevare vs skreddersydd

Med førstnevnte kan vi komme raskere i gang med å skrive kode og få et fungerende produkt, men det bringer også med seg mye overhead og kostnader ved kommersialisering. Alternativt kan vi lage et skreddersydd kort. Dette vil koste mer og ta lenger tid å utvikle, men samtidig står vi friere i valg av form og funksjoner, og produktet vil være billigere på sikt. Komponenttilgjengelighet vil også være en faktor.

Prosessor og power

I valg av prosessor må du ta hensyn til kravteksten for prosesseringskraft, kommunikasjonsprotokoller (f.eks. Bluetooth) og I/O for sensorer og styring (f.eks. UART, I2C, USB). Vær også oppmerksom på nyere krav til sikkerhet. Og så må du naturlig nok ha en kraftforsyning (power). Avhengig av om produktet skal drives fra veggstrøm eller batteri må du velge en regulator som passer. Her skal du også være oppmerksom på eventuelle ekstrakomponenter som kreves.

Valg av verktøy

Når komponenter er valgt, og det er blitt beskrevet hvordan de skal kobles sammen, starter vi å tegne skjema. For å kunne tegne skjema trenger man et program for å gjøre det. Et av de mest utbredte verktøyene brukt blant profesjonelle er Altium Designer. Den dekker de fleste behovene som en utvikler trenger i sin jobb. Med den kan en designe komplekse kort samt ha en nesten sømløs integrasjon med andre elektronikk- og mekanikkingeniører.

Open source-verktøy

På den annen side er KiCad en utfordrer som stadig blir bedre, er open source og gratis. Dette verktøyet er tilstrekkelig for mindre avanserte kort. Det at det i tillegg har et kommandolinjeverktøy gjør at en kan automatisere fabrikasjonsunderlaget enten lokalt eller gjennom Gitlab, Github eller lignende.

Grøtterød Vister vil ikke gi noen anbefaling av hvilket verktøy en skal bruke, siden det er avhengig av mange faktorer. En må tenke på hvilke funksjoner og egenskaper som en legger vekt på og velge det programmet som er best i den sammenhengen.

Skjemategning

For skjemategning er det vanlig å dele opp designet i ulike blokker alt etter funksjoner – det gjør tegningen mer oversiktlig og enklere å gjenbruke, evt. med justeringer. Hvis vi bruker et enkelt eksempel som vi har antydet over, kan det deles inn i prosessor (krever typisk mange passive komponenter i tillegg), periferi (for enkelt å se hvilke sensorer vi skal kommunisere med på utsiden), og kraftforsyning (som også har mange passive komponenter).

I/O og regler

Når vi har lagt inn de komponentene vi trenger, definerer vi ulike inn/ut-signaler, og setter opp regler for tidskritiske signaler som helst skal nå mikrokontrolleren samtidig. Det kan ha betydning for lederbredde og -lengde mm. Det vil også være regler for tykkelse og tetthet m.v. for å unngå kortslutninger og andre feil i powerdelen. Her skal man også tenke på å legge inn beskyttelseskretser for å hindre skade på elektronikken.

Husk gransking

Når skjemaet er ferdig, burde det alltid granskes av minst en annen elektronikkingeniør for å finne feil som kan gjøre at designet ikke fungerer slik det er tenkt. Dette gjøres ofte gjennom et granskingsmøte eller review. I dette møtet kan det også være lurt å kalle inn den eller de som skriver programvaren for elektronikken for å ta en sjekk av at pinnene på prosessoren og logikken i skjemaet faktisk er mulig.

Utlegg

Ved realisering, eller utlegg av skjemaet, tegner man de fysiske lederne og loddepunktene på kortet, med hensyn til reglene som er definert i skjemategningen. Utlegget vil også være avhengig av de fysiske begrensningene og designet på produktet. Dersom man har plass, kan det være et godt tips å legge ut ledere også fra pinner som ikke er i bruk på MCUen, for mulig fremtidig bruk. Andre ting å være oppmerksom på er skruehull og kontaktpunkter. Og om mulig, ta hensyn til produksjons- og testvennlighet ved plassering av komponenter og testpunkter. Her er det lurt å ha en løpende dialog med den personen som skal lage det mekaniske som går rundt kretskortet. Dersom eventuelle konflikter blir funnet og løst tidlig, vil dette være mye enklere og billigere å fikse enn senere. Det er alltid lurt å kalle inn mekanisk ingeniør/designer til review møtet for å godkjenne at kortet faktisk vil passe inn der det skal ligge.

Iterasjoner

Under designfasen er det viktig å ta høyde for flere runder, noe som kan vise seg svært nyttig for å forbedre designet. Et tett samarbeid mellom produkteier og utviklingshus/utvikler kan derfor ikke undervurderes, da det gjør det mulig med rask prototyping og testing underveis i prosessen.