Blog

Kwalitatief hardware design, deel 2: specificaties waarborgen

Kwalitatief hardware design: hoe pak je dat aan? Het eerste onderdeel, de definitiefase, bespraken we in een eerdere blog. In het tweede deel richten we ons op de volgende fase van hardware design bij de productontwikkeling: het waarborgen van specificaties. Aan de hand van ons eigen proces leggen we uit hoe je ervoor kunt zorgen dat de hardware eisen, die uit de systeemarchitectuur voortkomen, worden vertaald naar een design van hoge kwaliteit.

Een hardware design van hoog niveau

De eerste stap is om een hardware design van hoog niveau te maken. Hierbij maak je gebruik van traceerbaarheid van engineering requirements naar design decisions. Zo zorg je ervoor dat het design voldoet aan alle engineering requirements. Het design wordt zowel intern als extern beoordeeld. Omdat dit het meest creatieve deel van het hardware ontwikkelingsproces is, wil je de feedbackcyclus zo vroeg mogelijk in het proces starten.

Gedetailleerd design en schema’s opstellen

Daarna kunnen het gedetailleerde design en de schema’s worden opgesteld. Ook hiervoor geldt: dit is geen ‘big-bang’ aanpak. Het is een iteratief proces met veel interne feedback tussen de engineers. Het begint bij het bespreken van de werking van een circuit en eindigt met een formele review van het schema. Voor het reviewproces gebruiken wij het Altium 365 ecosysteem. Dit maakt het mogelijk om opmerkingen en taken direct in het schema te plaatsen. Voor deze review en iedere opmerking of taak hanteren we deze flow:

To do

New comment/task created in schematic and assigned to developer.

In progress

Developer reworks design to fix issue.

Resolved

If solution is approved the issue is marked resolved.

Een belangrijk onderdeel van de schema’s zijn de componenten die worden gebruikt in het design. Ieder component heeft de volgende eigenschappen:

  • Een schematisch symbool
  • Een of meerdere footprints (afhankelijk van de IPC-klasse)
  • Component parameters
  • Een bestelbaar onderdeelnummer (of meerdere)

Om de status van onze componenten bij te houden, heeft ieder component en footprint in onze database de volgende lifecycle:

New

Initial state after creation by the developer

Prototype

After a new component is reviewed by a colleague it transitions to the state 'prototype'

Production

When the component is proven to be correct in a prototype it is moved to the state 'production'.

Obsolete

Once a part is obsolete, or not to be used for some other reason, it is moved to the state 'obsolete'.

Release proces

Wanneer een design klaar is om gereleased te worden, creëren we een production package (TPD). Dit ‘pakketje’ bevat alle informatie die de fabrikant nodig heeft om de PCB te assembleren. Om er verzekerd van te zijn dat de output uniform, consistent en compleet is, wordt alle output in de TPD gegenereerd vanuit vooringestelde templates.

In het release proces worden ook automatische checks op het design uitgevoerd, waarbij de volgende onderdelen worden geverifieerd:

  • Voldoet het design aan de design rules?
  • Zijn er onopgeloste opmerkingen?
  • Wat is de staat van de componenten?
  • Zijn alle componenten beschikbaar?
  • Zijn alle ontwerpdocumenten opgeslagen in de cloudomgeving?

Zodra de check succesvol is afgerond, kan de release starten. Na uitvoering wordt de release getagged in de repository en kan het naar de fabrikant worden verstuurd voor productie.

slide-higo

Lifecycle management

Omdat onze componentendatabase gelinkt is aan de supply chain informatie van veel fabrikanten, kunnen we de beschikbaarheid van alle componenten in de gaten houden. Dat geldt ook voor de lifecycle van de fabrikant. Hiermee doen we ons voordeel: we scannen proactief op toekomstige supply chain problemen en zorgen ervoor dat onze designs produceerbaar zijn. Dit heeft extra toegevoegde waarde in de huidige markt, waarbij tekorten aan halfgeleiders een rol spelen.

Kortom, ook in hardware ontwikkeling is een iteratief proces van belang. Op deze manier kan snel worden gereageerd op geleerde lessen uit eerdere iteraties. Ook wijzigingen vanuit de klant, bijvoorbeeld door testen met prototypes, kunnen op deze manier worden meegenomen in het eindproduct. Wij zien wijzigingen dan ook niet als een obstakel dat vermeden moet worden, maar als belangrijk onderdeel van het ontwikkelproces. Met deze mindset kunnen specificaties worden gewaarborgd.

Lees ook onze andere blogs
Breid je kennis uit