Renoveringsverktyg för Telia Company
Telia Company AB erbjuder trådlösa loggningsenheter för bilar som kan revolutionera bilförsäkringen. Genom att logga förarens körmönster kan försäkringsbolagen erbjuda verkligt individuella försäkringar. Försiktiga förare behöver inte längre subventionera vårdslösa förare. Om en kund säger upp sin försäkring ska loggningsenheten renoveras, vilket innebär att tidigare data ska rensas och enheten ska återinstalleras, eventuellt även uppgraderas och testas, så att den kan återanvändas igen. Utvecklingen av ett sådant renoveringsverktyg innebär ett antal utmaningar. Telia Company anlitade Novator Solutions för att ta itu med dessa utmaningar.
Teknisk utmaning
- Flera bussar och protokoll
- Icke-standardiserade protokoll
- Hög kapacitet, användarvänlighet och utbildning av operatörer
- Behov av lågt underhåll och möjlighet till uppgradering
Lösning
- Avancerad och modulär kommersiell standardhårdvara med omkonfigurerbar FPGA
- Parallellkörning av flera enheter i samma högautomatiserade testprogramvara för renovering baserad på branschstandardverktyget NI TestStand
- Abstraktionslagerarkitektur för hårdvara för att möjliggöra framtida uppgraderingar
Affärsutmaning
- Hårdvarutestning utanför kärnverksamheten
- Begränsad intern expertis
- Behov av att stödja flera enhetsleverantörer med samma plattform och renoveringsprocess
- Kort tidsschema
- Nödvändigt för att undvika finansiell risk
- Flera intressenter
- CE-märkning och dokumentation
Lösning
- Fullt ansvar för projektledning, utveckling och leverantörskommunikation
- Projekt med fast pris
- Fullt ansvar för CE-märkning och dokumentation
Enhet under test
Den enhet som testas (DUT) är en omborddiagnosenhet med ett integrerat 4G-modem som kontinuerligt överför kördata till försäkringsbolaget. Dess elektriska signaleringsprotokoll och pinouts definieras i OBD-II-standarden. Olika biltillverkare använder olika delmängder av de tillgängliga protokollen och bussarna, vilket innebär att enheterna måste stödja ett stort antal kombinationer av pinouts och protokoll. Under en fullständig renoveringsprocess måste funktionen hos alla dessa testas. Testsystemet måste stödja kommunikation av standardprotokoll, såsom CAN, J1850 VPW, J1850 PWM och ISO9141, samt anpassade protokoll för styrning av DUT och nedladdning av nya firmware.
Testsystemets arkitektur
Hårdvarugränssnitten är implementerade på en NI CompactRIO och ett nätverkskommunikationslager används för att upprätta kommunikation med en PC som kör en testsekvens som utvecklats i NI TestStand. TestStand är en allmänt använd testledare och ett ramverk för vanliga uppgifter inom en produktionstestmiljö, som hanterar allt från sekvensering av teststeg till rapportgenerering och molndatabasintegration. Genom att separera de DUT-specifika funktionerna i testsystemet från vanliga uppgifter i en testmiljö kunde mycket av funktionaliteten i NI TestStand-miljön utnyttjas för att tillhandahålla en komplett och beprövad lösning för parallell testning av flera enheter.
Abstraktion av hårdvara och testuttag
Ett drivrutinslager har utvecklats för att hantera lågnivåkommunikationen med DUT och ett objektorienterat hårdvaruabstraktionslager (HAL) har utvecklats för att koppla varje testuttag till de tillhörande pinnarna på IO-modulerna. Varje testuttag är associerat med en separat uppsättning av drivrutinsobjekt för att möjliggöra oberoende exekvering på någon av de initialiserade testuttagen. Protokollen implementerades på en FPGA som hanterar in- och utmatningsbuffertar samt sänder och tar emot de fysiska signalerna. Implementeringen är hårdvarutimad och har parallella implementeringar av alla kommunikationsprotokoll och IO-buffertar. För att minska kabeldragningen skapades ett specialdesignat kretskort för det fysiska gränssnittet mot DUT:n. Denna arkitektur möjliggör ett flexibelt utförande av teststegen och eftersom de lägre lagren generaliseras och abstraheras kan systemet uppdateras för att hantera nya typer av OBD-gränssnitt med minimala modifieringar.
CompactRIO-plattformen innehåller en realtidsprocessor och en FPGA, båda programmerade med LabVIEW, samt ett brett utbud av IO-moduler. Realtidsprocessorn hanterar och utför de teststeg som beställs av testledaren.
FPGA:n ger flexibilitet för att uppfylla behoven för alla protokollimplementeringar, vilket möjliggör snabb utveckling av ett gränssnitt för att kommunicera med DUT med hjälp av ett leverantörsdefinierat icke-standardprotokoll, t.ex. för att ladda upp firmware till DUT.
Utbudet av standardiserade IO-moduler förenklade systemdesignprocessen och minskade den tekniska risken i projektet. Den enda PCB-utveckling som behövdes var adapterkortet för gränssnittet med DUT:erna via standardiserade kablar och kontakter, som främst användes för att undvika överdriven kabeldragning.
Förutom att påskynda utvecklingsprocessen förenklar användningen av kommersiell hårdvara framtida underhåll och replikering genom att erbjuda en mycket hög flexibilitetsnivå och fungera som en plattform som kan utökas när nya DUT:ar introduceras.
Novator Solutions utvecklingsprocess
Novator Solutions använder Scrum-processen för att hantera vårt utvecklingsarbete. Scrum är ett lättviktigt, iterativt och inkrementellt ramverk för att hantera komplext arbete. Ramverket utmanar antaganden om det traditionella, sekventiella tillvägagångssättet för produktutveckling och gör det möjligt för team att självorganisera genom att uppmuntra fysisk samlokalisering eller nära samarbete online för alla teammedlemmar, samt daglig kommunikation ansikte mot ansikte mellan alla teammedlemmar och discipliner som är inblandade.
För våra kunder innebär detta en effektiv prioritering och en rak kommunikation under projektets gång. Allt för att säkerställa högsta möjliga kundnöjdhet med slutresultatet samt det mest kostnadseffektiva sättet att nå den önskade lösningen. Vid utveckling av kompletta system kan vi ta ett helhetsansvar för hela utvecklingskedjan: Från sammanställning av kravspecifikationen via design och konstruktion av mekanik, pneumatik och elektronik till utveckling och installation av programvara och databaser. För att hålla högsta nivå på alla delar i varje system använder vi oss alltid av pålitliga och certifierade partners inom områden som ligger utanför vår egen expertis.
Novator Solutions prismodeller
Novator Solutions erbjuder två typer av prismodeller för nyckelfärdiga system, Fast pris eller Time & Materials. Utvecklingen sker alltid med hjälp av det agila programmeringsramverket Scrum.
Fast pris
I ett fastprisprojekt bestäms leveranserna och hur de ska utvärderas innan projektet startar. Vid behov kan Novator Solutions utföra en förstudie för att hjälpa kunden att identifiera kraven.
När vi har fastställt kraven lämnar vi en offert med ett totalpris för ett system som uppfyller kraven, inklusive acceptanstester i fabrik och på plats som ska utföras för att verifiera funktionaliteten vid leverans. En produktägare utses av Novator Solutions och vi utvecklar systemet som uppfyller de redan överenskomna kraven.
Proffs
- Ingen finansiell risk - kunden vet från dag ett vad de kommer att betala
Nackdelar
- Begränsad möjlighet att omprioritera leveranser efter beställning - leveranser måste valideras noggrant före projektstart.
- Begränsad möjlighet till beta-testning eller förhandsreleaser. Vi arbetar enligt kravdokument och testar program tills full funktionalitet kan levereras.
- Åtagande att betala för hela systemleveransen även om viss funktionalitet omprioriteras.
Tid och material
I ett Time & Materials-projekt sätts en omfattning för projektet. Ofta bestäms också en lista över leveranser och helst hur de ska utvärderas, och Novator Solutions ger en uppskattning av den tid vi tror att det kommer att ta att implementera systemet.
En produktägare utses av kunden och en projektledare av Novator Solutions. De håller tät kontakt under hela projektet och träffas med jämna mellanrum för att omprioritera, ändra eller dra ner på leveranslistan för att få bästa möjliga system med minsta möjliga investering.
Proffs
- Valideringsarbetet av leveranserna kan göras mindre noggrant, vilket sparar tid.
- Kunden kan testa betaversioner av systemet och ändra leveranserna för att optimera det under hela projektet.
- Projektet kan avslutas så snart den önskade funktionsnivån har uppnåtts. Eller så kan en första version driftsättas medan vi fortsätter att arbeta med uppgraderingar.
Nackdelar
- Kunden måste ta den ekonomiska risken för en beslutad uppsägningstid.
Oavsett vilken leveransmodell som väljs är vi alltid engagerade i att de system vi levererar ska fungera på lång sikt. Vi erbjuder serviceavtal för att garantera drifttid och kontinuerliga uppgraderingar samt för att minska risken för att komponenter blir föråldrade.