PROSJEKTER
Del artikkel
Skrevet av: Kristian Husevåg Krohn (Senior Development Engineer)
Hardware kan ha defekter, og utsortering av enheter med feil på et tidlig tidspunkt i produksjon kan føre til mindre avfall ved å ikke fortsette produktsammenstilling med defekte komponenter.
Når man utvikler en produksjonstest-applikasjon for høyvolum produksjon kan det være smart å tenkte ut noen designmål på forhånd. Ofte kan de se ut noe som det her:
En fornuftig abstraksjon å starte med kan være på toppen av driverlaget. Det vil abstrahere bort smådetaljer rundt hver enkelt periferienhet, men er likevel tilstrekkelig lavt til å ikke bli påvirket av implementasjonsdetaljene til applikasjonskoden din. Dette vil også hjelpe til å holde produksjonstest-applikasjonen ganske selvstendig og vil forhåpentligvis ikke brekke når en ivrig applikasjonsutvikler oppdaterer et bibliotek. En annen god idé kan være å lage et rammeverk for å putte alle testene inni. På denne måten kan det bli enklere å håndheve en standardisert testgjennomføring, testdokumentasjon som beskriver hva testen dekker og hvordan man skal bruke den, samt logging og kommunikasjon med testmaskinen. Alt dette vil gjøre scripting av testprosedyren til en drøm i enten testmaskinen eller på enheten, og vil også gjøre det ganske enkelt å vedlikeholde i fremtiden.
Når man definerer et sett med funksjonalitet som skal inngå i et produksjonstestrammeverk så foretrekker jeg å ikke gå i beina på den som faktisk skal skrive testene (meg) ved å ha testene som funksjonspekere til gode gamle int test_whatever(const char **argv, int argc) og sende inn parameter som en vanlig applikasjon. Jeg liker å tenke på rammeverket som et program med programmer. Når jeg registrer testene foretrekker jeg å gjøre det uten å rote til selve rammeverket, og holde alt som er relatert til en test inni en enkelt fil og heller styre hva som blir med i applikasjonen med Makefile/CmakeLists.txt fila. Når det kommer til logging foretrekker jeg å definere mine egne loggefunksjoner sånn at jeg kan både printe til stdout og fil.
Et typisk tilfelle for en produksjonstest er perifierienheter til prosessoren. Du trenger ikke teste hver enkelt funksjon til periferienheten. Chipen/modulen er sannsynligvis ok og testet av produsenten, den store ukjente faktoren er din egen PCBA. Når du kan kommunisere med periferienheten er den sannsynligvis ok, prøv å holde testene på det samme nivået. Et unntak er når den er koblet videre til noe annet. La oss si du har en ekstern Ethernet-kontroller som i sin tur er koblet videre til en Ethernet PHY, gjennom en trafokobling og ut til RJ45-kontakten. For å ha noe konfidens på at Ethernet funger som det skal må du teste hele kjeden, enten med en loopbackkabel, eller å koble den til switch for å se at du får link. Det er imidlertidig nok å se at du har link for å kunne si at Ethernet er ok, og noe mer inngående testing bare vil forsinke testgjennomføringen.
Dette vil komme til å bli et veldig hendig verktøy for andre utviklere, testere og annet personell på prosjektet. Selv om det kan være greit å legge til tester som ikke skal bli kjørt i produksjon er det viktig å ikke miste fokus på målet, spesielt når prosjektledelsen eller salg finner ut om dette fantastiske verktøyet som kan få hardwaren til å gjøre ting lenge før prosjektet er ferdig.
Et siste tips er at du har kanskje ikke lyst til å la dette verktøyet bli liggende igjen på enheten når man sender ut produktet til kunde. For det første ser det ikke så bra ut å ha interne produksjonsverktøy liggene igjen på enheten, og for det andre har du kanskje funksjonalitet som du ikke vil at kunder skal tukle med, som å kunne sette powerrails til nivåer der hvor blårøyken begynner å sive ut.
Så for å oppsummere: Test hardware, ikke software og planlegg for skalering, scripting og hurtig endring av testsettet.
R&D Manager
https://rd-datarespons.no/wp-content/uploads/2024/08/defense-2.jpg
888
1265
Henrik Eriksen
https://rd-datarespons.no/wp-content/uploads/2024/04/RD-Akkodis-logo_bigger.svg
Henrik Eriksen2024-08-14 14:23:362024-08-14 14:23:36Defense Technology 2024
https://rd-datarespons.no/wp-content/uploads/2024/06/iStock-1134160053.jpg
810
1296
Henrik Eriksen
https://rd-datarespons.no/wp-content/uploads/2024/04/RD-Akkodis-logo_bigger.svg
Henrik Eriksen2024-06-17 12:52:182024-06-17 12:52:18Bluetooth Mesh: Robust Communication for the next IoT system
https://rd-datarespons.no/wp-content/uploads/2024/01/iStock-1494104649_2.jpg
768
1095
Henrik Eriksen
https://rd-datarespons.no/wp-content/uploads/2024/04/RD-Akkodis-logo_bigger.svg
Henrik Eriksen2024-01-08 09:22:102024-01-10 08:53:40Exploring a Safe Integration of AI and Business
https://rd-datarespons.no/wp-content/uploads/2024/08/defense-2.jpg
888
1265
Henrik Eriksen
https://rd-datarespons.no/wp-content/uploads/2024/04/RD-Akkodis-logo_bigger.svg
Henrik Eriksen2024-08-14 14:23:362024-08-14 14:23:36Defense Technology 2024
https://rd-datarespons.no/wp-content/uploads/2024/06/iStock-1134160053.jpg
810
1296
Henrik Eriksen
https://rd-datarespons.no/wp-content/uploads/2024/04/RD-Akkodis-logo_bigger.svg
Henrik Eriksen2024-06-17 12:52:182024-06-17 12:52:18Bluetooth Mesh: Robust Communication for the next IoT system
https://rd-datarespons.no/wp-content/uploads/2024/01/iStock-1494104649_2.jpg
768
1095
Henrik Eriksen
https://rd-datarespons.no/wp-content/uploads/2024/04/RD-Akkodis-logo_bigger.svg
Henrik Eriksen2024-01-08 09:22:102024-01-10 08:53:40Exploring a Safe Integration of AI and Business
Secure boot