Richard Newman har tillbringat 20 år av sitt liv i mjukvaruindustrin. Karriären började på Northrop Corporation med tillämpningar inom flyg- och rymdindustrin. På Printronix jobbade han som chefsprogrammerare för olika projekt. Idag är han på Wind River och hans första jobb där var som teknisk redovisningschef. Efter åtta år blev han teknisk expert i gruppen som jobbar med hanteringen av drivrutiner. Richard Newman har en ingenjörsexamen i datavetenskap och den tog han tog på University of California, Irvine.

En sensorpunkt är ett självständigt, färdigkompilerat och färdiglänkat litet stycke programkod. Den definieras i termer av de funktioner, globala variabler, lokala variabler och kodrader som finns i en given C-kodsfil.

Binärkoden för sensorpunkten kan länkas in och ut dynamiskt ur RAM-minnet i adresser som specificeras i sensorpunkten. En och samma sensorpunkt kan användas som patch på flera olika ställen i samma kompilerade C-program. Patchningen kan ske utan att programmet avbryts.

Sensorpunkter kan konstrueras i samband med produktutvecklingen. Men de kan också skapas i efterskott, när produkten redan varit i bruk i åratal. Sensorpunkterna lagras på en särskild hanteringsserver (DMS, Device Management Server) som både utvecklare och testare har åtkomst till.

En sensorpunkt är en prob som når ända fram till enstaka källkodsrader. Och som omedelbart kan tas bort. KLICKA FÖR ATT SE HELA BILDEN

Wind Rivers Lab Diagnostics ger utvecklings- och testgrupper gemensam access till uppgifter om produkten rörande både prestanda och tid-för-fel under test och administration. KLICKA FÖR ATT SE HELA BILDEN

Under den initiala utvecklingsfasen kan man använda sensorpunkter för unit testing. Sensorpunkter utvecklas parallellt med applikationskoden för att testa den. De kan exempelvis göra loggutskrifter med hjälp av printf. Eller anropa en kodslinga för att testa den. Eller undersöka ett beräknat värde i en algoritm. De kan också användas för att simulera hårdvara som ännu inte existerar, fylla buffertar, ställa registervärden, eller för att driva svar från ickeexisterande hårdvara.

Under systemintegrerings och testfasen kan sensorpunkter sköta koordinering genom att interagera med semaforer, globala variabler och så vidare. Under storskaliga integreringstest kan en sensorpunkt driva, eller drivas av, andra sensorpunkter.

Vid kvalitetstestning kan man integrera sensorpunkter i testprocedurerna. Kvalitetsgruppen kan beställa nya sensorpunkter med nya funktioner om det behövs för granskningen. Dataloggar sparas för att kunna plockas fram för jämförelse vid produktlanseringar.

Under tillverkningsfasen accessas sensorpunkter från servern i syfte att isolera problem. Loggar sänds direkt till test- och konstruktionsgrupperna. Tillverkningsgruppen kan begära ytterligare sensorpunkter för att programmera utrustning eller tillhandahålla specifika hårdvaru- eller mjukvarutest som körs innan utrustningen skickas ut, inklusive slutlig utrustningskonfigurering.

Ute på fältet kan en sensorpunkt användas för diagnostik. Eller till och med för att addera nya funktioner. Ett supportcenter kan accessa sensorpunkter för att generera felloggar, köra nya tester, installera programfixar eller för att samla information om prestanda. Och allt detta direkt från utrustning som redan är installerad och körs på plats hos kunden.

Ytterligare funktionalitet kan göras tillgänglig genom uppdatering av programvara, rättelser av nya funktioner, fjärrkonfigurering av utrustning och insamling av statistik på användningen. Och det går fortfarande bra, för den som vill, att lägga till helt nya sensorpunkter.

Alla projekt kommer förr eller senare till en tidpunkt då ingenjörerna är nöjda med sitt arbete (eller har förbrukat sin sista deadline) och programvaran skickas till testlabbet. Drömmen är att programvaran överlämnas en enda gång, glider igenom alla tester utan varningslampor och langas direkt vidare till tillverkning. Men verkligheten ser förstås snarare ut så här:

1. Produkttestning påbörjas i testlabbet
2. Defekter upptäcks
3. Konstruktionsgruppen återskapar de flesta av defekterna
4. Programvaran modifieras i enlighet med detta, och lämnas återigen till kvalitetstestning
5. Produkttestning påbörjas igen

Steg 2 till 5 upprepas tills produktkvaliteten når en acceptabel tröskel.

Om du med standardmetoder vill aktivera ett stycke avlusningskod i en funktion, krävs en omkompilering av åtminstone den funktion som berörs. Därefter måste koden länkas och installeras på målet. Länkningen kan i vissa fall ta flera timmar och koden måste flashas upp på målet. Samma arbetsgång gäller om du vill testa modifierad kod eller ändra värdet på en konstant.

Dessutom kan avlusningskoden i sig förändra systemets beteende, vilket leder till att problemet gömmer sig och dyker upp igen senare under konstruktionsarbetet, eller ännu värre, under nästa testomgång.

Med sensorpunkter kan du minska utvecklings- och testningstiden samtidigt som du förbättrar kvaliteten på den verifiering och validering som faktiskt utförs. Du kan:

• stoppa in avlusningskod (inklusive loggar och printfs) som lokaliserar programfel
• stoppa in kod som testar programfixar
• undersöka och ändra värden på variabler, register och sensorer för att validera programfixar
• modifiera systemet utan vare sig omstart eller extra tester

Sensorpunkter kan minska antalet upptäckta fel. Omfattande enhetstestning och integreringstestning kan visserligen minska antalet programvarufel som senare upptäcks under verifiering och validering. Samtidigt kan man försena lanseringen av en produkt genom att ägna för stora resurser åt det. Testsviterna är dessutom ofta föråldrade, kräver omständlig installation. Och testar mer än det som egentligen behövs - exempelvis kanske man överför en komplett uppsättning parametervärden till en funktion för att testa den, istället för att bara överföra de specifika värden som behövs för att testa logiken.

Programvaruingenjörer kan använda sensorpunkter för att:

• sätta värden på variabler
• tvinga villkorsuttryck att exekvera vissa kodstigar
• injicera fel för rutiner som normalt inte returnerar fel, som exempelvis malloc
• förändra systemets miljö (till exempel ändra sensorvärden, sätta värden på CPU-register och på styrregister till kringutrustning, eller modifiera strömmande data)

Tester som används för validering och verifiering formuleras till en början utgående från produktspecifikationer och användarhandböcker. Men allt eftersom testandet framskrider, ökar testsviternas volym. Efter många månaders testning, har testsviterna blivit så stora att de måste köras i timmar i sträck, och de resulterar i enorma mängder data att undersöka. Dessutom är labbuppställningen för många tester en flera timmar lång process som kräver ytterligare testingenjörer och testutrustning.

Sensorpunkter kan användas för att sätta fokus på specifika tester, till exempel genom att:

• manipulera utrustningsmiljön in i ett specifikt tillstånd, till exempel genom att fejka ett högt värde på en temperatursensor eller genom att framkalla specifika fel
• direkt försätta utrustningen i ett tillstånd som den kanske annars bara skulle ha kunnat anlända till efter flera timmars kontinuerlig drift, genom att exempelvis fylla buffertar, tömma köer. Eller kanske genom att beräkna ? med 40-miljoner decimaler, om det är vad som krävs.
• ta bort behovet av sofistikerad testutrustning genom att exempelvis sätta hoppräknar i ett datapaket till ett högt värde
• möjliggöra tester inriktade på ett specifikt delsystem. Eftersom sensorpunkter kan injiceras var som helst i programvaran, kan de användas både för att bestämma utrustningens externa miljö och dess interna tillstånd (såväl mjuk- som hårdvara) och slutligen för att köra utrustningen och samla testinformation
• göra det möjligt för testgruppen att köra och testa hårdvara. Eftersom sensorpunkter kan förändra värden på variabler och anropa funktioner, kan de användas för att starta och stoppa maskineriet i en utrustning, för att visa på dess begränsningar i exempelvis inklusive räckvidd eller repetitivitet

Med hjälp av hanteringsservern kategoriseras och lagras de sensorpunkter som skapas av programvaruingenjörerna under utvecklingen. Verifierings- och valideringsgrupperna använder dem för att utföra de specifika tester som behövs under denna fas av utrustningsutvecklingen. Tänk dig sensorpunkter med namn som ”buffert tom”, ”slut på magenta”, ”IP-routingprestanda”, ”hög syrenivå” eller ”fånga seriell data”. Tänk dig dem som testprocedurer som du alltid har tillgång till. Det ger dig en idé om hur sådana tester kan göras specifika för en viss produkt eller process.

Sensorpunkter hjälper till att fokusera på orsaken till fel genom att de kan

• tvinga systemets tillstånd att återskapa felet genom att ändra systemets miljö
• spåra globala och lokala variabler, funktionsanrop och data vid återskapandet
• tidsstämpla samtliga punkter i systemet för att upptäcka fel i timing eller prestanda
• inkorporeras i testskript exempelvis för att generera och samla in loggar
• generera testloggar som lagras i hanteringsservern omedelbart tillgängliga för teknikavdelningen för att avlusa problem, skapa programfixar och minska antalet fel på rekordtid

Vi är därmed borta från situationen att testavdelningen endast använder sig av programingenjörerna för att återskapa själva felet. Istället kan kvalitetstestavdelningen direkt förse konstruktörerna med information som hjälper dem förstå vad som orsakar problemet.

Också tillverkningen måste validera en produkt innan den kan paketeras och köras iväg. Tillverkningsgruppen kan definiera egna sensorpunkter som exempelvis provar hårdvara eller söker tillverkningsdefekter.

Sensorpunkter kan användas för att förbättra den interna kommunikationen. Olika ingenjörs- och testgrupper kan alla på sitt sätt bidra med information som sedan blir gemensam via sensorpunkter och testloggar i servern.

Via sensorpunkter kan man inte bara dela data över rummet mellan olika grupper. Utan också över tiden. Värdefull kunskap om en produkt försvinner ofta när en ingenjör byter jobb. Sensorpunkter är ett sätt att fånga och hålla kvar dessa ingenjörers kunskap.