Testprogramspråk i Autotestare

Skrivet av Lars-Olov Larsson

INNEHÅLL

Allmänt

Testarspecifika språk

Allmänt

Den här artikeln beskriver de testprogramspråk som användes i autotestare under ca 30 års tid. Helt naturligt så är skillnaden mellan språken som användes i början och de som användes i slutet av perioden stor. Det är inte bara det att andra testprogramspråk användes i slutet av perioden. Ta t. ex språket BASIC som användes under en stor del av tiden. Det fanns en hel del skillnader mellan den första och senaste versionen.
I början användes mest testarspecifika programspråk, men så småningom kom generella programspråk att användas mer och mer, som t. ex BASIC. En del lite udda testare som kom till i ett senare skede hade också testarspecifika programspråk. Ett system för test av minneskretskort och ett system för komparatortest kan speciellt nämnas. Komparatortest för kretskort innebar att det kretskort som skulle testas jämfördes mot ett exakt likadant felfritt kretskort.

Testarspecifika språk

I den första testaren, som levererades av ELLIOTT, bestod testprogrammet av en stansad hålremsa med kommandon som kunde läsas av datorn. Nästa testare, den s. k. HAC testaren, levererades av Hughes Aircraft Company, var något mer avancerad. Här lagrades testprogrammet i datorns minne, men språket var helt unikt för HAC.
Nästa testare som levererades av LM Ericsson (LME) hade en av LME egenutvecklad dator. Datorns beteckning var UAC 1601. Testprogrammen skrevs i ett egenutvecklat testprogramspråk. Innan programmet kunde exekveras måste det först kompileras på ett stordatorsystem.

En liten programsnutt för detta system skulle kunna se ut så här:
          .
          .
   0100 SSIN     5.5V 2HZ A10070 K10070
     0200 VÄNTA 2S
     0300 MIT       2HZ 4.6V 4.4V K10410 K10411
          .
          .
För test av minneskort inköptes ett system från ADAR. Med systemet följde programvara med vilken det var möjligt att utveckla testprogram som skrev och läste i minnets olika delar. Det fanns också funktioner för att testa kretskortets styrelektronik.
FLUKE levererade ett nyckelfärdigt system för komparatortest. Programvara för att utveckla testprogram ingick också.

BASIC

I och med att man gick över till att använda testsystem från Hewlett Packard (HP), kom också BASIC att användas. BASIC var en förkortning för Beginners All Symbolic Instruction Code.
BASIC ansågs ha många fördelar, för att nämna några:

Språket var lätt att lära.

Språket var interpreterande vilket innebar att den kod som skrivits tolkades direkt vid exekveringstillfället. Härigenom kom man ifrån den många gånger omständliga kompilerings och länkningsprocessen, som för datorovana personer kunde ställa till mycket problem. När kompilerande programspråk användes var man ofta tvungen att flytta över källkoden till ett annat system för kompilering och länkning, när detta var klart flyttades resultatet tillbaka till testsystemet. Det var heller inte säkert att systemet där kompileringarna gjordes och testsystemet fysiskt stod på samma plats.

I och med att vi hade tillgång till källkoden för BASIC interpretatorn kunde vi själva modifiera den. Detta gjordes också till viss del.

Den version av BASIC som användas var väldigt primitiv och kan på intet sätt jämföras med dagens oerhört kraftfulla varianter av BASIC. Den hade ett antal språkelement. Följande kan nämnas.
- LET för att tilldela en variabel ett värde
- + - x / för att utföra matematiska beräkningar
- möjligheter att anropa matematiska funktioner såsom sin, cos, tg, cot, exp, lg
- IF för att jämföra två storheter
- FOR.....NEXT för att kunna göra loopar.
- CHAIN och LINK för att länka till subrutiner och program.
- GOTO för att hoppa till ett visst radnummer.
- INPUT/OUTPUT för att kommunicera med omvärlden.
- REM för att ange att det är en kommentarsrad.

Det som var unikt med den BASIC som användes var möjligheten att anropa instrument funktioner eller macros som det också kallades. Denna funktion hade realiserats genom att BASIC hade kompletterats med 2 st tabeller som kallades call och mnemonic tabellerna. I calltabellen specificerades de parametrar som en instrumentfunktion kunde anropas med, både typ och antal. I mnemonic tabellen specificerades namnet på instrumentfunktion (macrot).

Att ställa upp signalvägen, stimulera en insignal, göra en spänningsmätning och utvärdera resultatet mot en undre och övre gräns skulle då kunna se ut så här.

                   200 REM Ställ upp signalvägen för stimuli
                   210 SANS(3,0,0,0,1,0)
                   220 REM Ställ upp 10 Volt
                   240 SLS(3,10)
                   300 REM Anslut mätkanaler
                   310 MANS(118,0)
                   320 MANS(3,0,0)
                   330 REM Utför mätningen
                   340 MDVMA(2,10,M)
                   350 REM utvärdera mätresultatet mot gränserna 9 och 11 Volt
                   510 UTV (M,9,11)

Hur testprogrammen skulle utformas och tas fram fanns noggrannt beskrivet i ett regelverk som kallades PVA (Program Varu Arbete). När man pratade om testprogram kallade man dem alltid för tester.

TESTAID

För att ta fram digitala testdata användes en simulator som kallades TESTAID. Den utvecklades av HP.
TESTAID bestod i huvudsak av 4 st program nämligen SIGLIST, SIMSET, SIMULA och PATDOC.

SIGLIST användes för att beskriva det kretskort som skulle testas och överföra det till en datormodell. Det var också möjligt att i beskrivningen länka till bibliotek där färdiga beskrivningar av många integrerade kretsar redan fanns framtagna.

SIMSET omformade datormodellen så att den blev lämplig för simulering, samt beräknade antal fel som kunde uppträda på kretskortet.

SIMULA används för att generera testmönster och simulera kortets funktion för respektive testmönster.

PATDOK användes för att konvertera programvarumodellen och simuleringsresultatet så att det kunde användas för det slutliga testprogrammet. I PATDOK fanns också funktioner för inmatning av adapterinformation, vilken relaterar anslutningspunkter i testobjektet till in/utgångar i testaren, samt av värden på fördröjningar.
Ytterligare en funktion var att man kunde ange att efter ett visst testmönsternummer skulle testerna utföras i ett annat språk t. ex BASIC eller FORTRAN. Man sade då att man ”Branchade”. Branchning till BASIC program var synnerligen tidskrävande jämfört med FORTRAN program, men det var enklare att skriva BASIC program, så många gånger blev det en avvägningssak.

TESTAID var vad vi idag kallar en statisk simulator, som bland annat innebar att möjligheten att specificera tider var mycket begränsade.

FASTRACE

TESTAID och FASTRACE hör mycket nära ihop. Grovt kan man säga att TESTAID användes för framtagning av testmönster och FASTRACE för exekveringen.
FASTRACE bestod av ett antal program. De viktigaste var SETUP, CHECK, PONOFF, GONO och PROBE.

SETUP användes för att specificera hårdvaran i testutrustningen, såsom vilka kort som satt i DTUn (Digital Test Unit) och vilket slot de satt i (fack). Vidare angavs adapterkoden. Adapterkoder användes som kontroll för att rätt adapter (kontakt) skulle användas vid anslutning av testobjektet. Varje adapter hade en unik kod. Referensnivåerna för de programmerbara korten i DTUn kunde också anges.

CHECK var ett kontrollprogram som användes för att kontrollera att det som hade angetts i SETUP överensstämde med vekligheten, dvs att angiven hårdvara verkligen fanns i testutrustningen och att den satt på rätt plats.

PONOFF var ett program för att ansluta och koppla ner kraften till ett testobjekt.

GONO utförde pass/fail test (rätt/fel test) på varje kretskort som testades. Under en GONO test skickades alla testmönster i testdatafilen till kretskortet. Kretskortets svar på mönstret jämfördes mot det svar som TESTAID hade kommit fram till för ett felfritt kort vid den tidigare simuleringen.

PROBE används huvudsakligen för felisolering när ett testmönster inte gett ett förväntat response vid en GONO test. Instruktioner för var man skulle proba (Mäta) gavs. Efter ett antal probningar kom man fram till den felaktiga komponenten som då byttes ut. Därefter upprepades testen för att verifiera att kretskortet nu var felfritt.

Fortran

Fortran (Formula translation) är ett mycket gammalt programspråk. Det skapades under 50-talet av IBM under ledning av John W Backus. Språket var mycket väl lämpat för matematiska beräkningar. Inom autotesttekniken användes det i ett system för test av tröghetsnavigeringsutrustning. Närmare bestämt var det för att ta fram korrektionsfaktorer för gyron.

VETO

Detta språk skapades av LM Ericsson. Det användes huvudsakligen för test av kretskort i telefonväxlar. Språket var i huvudsak inriktat på digitaltest, men hade också statements för analoga tester.
Bakgrunden till språket är den här, i alla fall som det har berättats för mej. En av LME's chefer hade varit på en konferens där man hade presenterat ett programspråk där man i klartext på ett språk som påminde om engelska kunde specificera testprogrammet. Dessutom var det oberoende av testutrustning, språket hette ATLAS. Resultatet av det hela blev att man beslöt sig för att införskaffa en ATLAS kompilator. Valet föll på ett engelskt företag. När man började använda kompilatorn visade det sig att den inte alls var uttestad och de ATLAS statements som fanns var inte speciellt lämpade för de digitaltester som man ville utföra.
Man tog då ett drastiskt beslut att lämna ATLAS och utveckla ett eget testprogramspråk, specialdesignat för att utföra de tester man ville. Gruppen som höll på med detta arbete jobbade på en avdelning som hette VTO. Därför beslöt man att kalla språket VETO.

Vid upphandlingen av testsystem för JAS beslöt man att VETO skulle användas för digitaltest.

ATLAS

Detta språk specificerades under 50-talet av flygindustrin. ATLAS var en akronym för Abbreviated Test Language for Avionic Systems. ATLAS var i början ett rent specifikationsspråk, men började efterhand även att användas som programmeringsspråk. Grundidén med språket var att det skulle påminna om engelska språket så att en som inte var programmeringskunnig kunde se vad som gjordes. Det skulle vara självdokumenterande och oberoende av testutrustning.
Så småningom flyttades utvecklingen av språket över till IEEE (Institute of Electrical and Electronics Engineeres). Det fick också ett nummer och det var 416. Hädanefter kallades språket för ATLAS-416. I detta sammanhang ändrades också betydelsen av akronymen som nu blev Abbreviated Test Language for All Systems.
Så småningom definierades nya subset av ATLAS. De militära användarna, även kallade ”The five major users” definierade en variant som fick beteckningen ATLAS-716 eller C/ATLAS som den också kallades. I ”The five major users” ingick US Dod, UK Mod, French Mod, German Mod och ARINC (De civila flygbolagen). Så småningom blev även Swedish Mod medlem i ”The five major users”.

Ett tredje ATLAS subset definierades av ARINC som fick beteckningen ATLAS-616.
Inom JAS projektet togs ett beslut att ATLAS skulle användas som programmeringsspråk. Den version som valdes var C/ATLAS. Efter utvärdering av ett antal tänkbara leverantörer fastnade man för det tyska företaget GPP (Gesellschaft für prozessrechnerprogrammirung). De hade en intressant teknik för att åstadkomma flyttbara program. Den gick ut på att testarutrustningen och samtliga instrument och instrumentfunktioner beskrevs i detalj i ett speciellt språk. Beskrivningen kompilerades sedan och man fick som resultat en ATE modell. Anslutningen av testobjektet till testaren beskrevs i en adapterfil som kompilerades och resultatet blev en adapterlista.
Det framtagna ATLAS programmet kompilerades sedan mot ATE modellen och adapterlistan.
Uppgraderades testutrustningen med andra instrument eller om programmet exekverades på ett annat testsystem var det bara att modifiera ATE modellen och adapterlistan. ATLAS programmet kunde på så vis hållas helt intakt.

En snutt ur ett ATLAS program skulle kunna se ut så här:
                .
                .
C Ställ upp en DC Signal om 10 Volt mellan punkterna J1 och J2 på testobjektet.
       APPLY, DC SIGNAL,
                     VOLTAGE 10 V,
                     CNX HI J1 LO J2$
C Mät nivån av en AC Signal mellan punkterna J3 och J4
       MEASURE, (VOLTAGE INTO 'MVAL'), AC SIGNAL,
                           VOLTAGE RANGE 10.9 V TO 20.5 V,
                           FREQ MAX 50 Hz,
                           CNX HI J3 LO J4$

HILO

I och med att VETO valdes som testprogramspråk för digitaltest i de testutrusningar som skulle användas i JAS projektet behövdes också en simulator. LME hade redan en som var specialanpassad för VETO. Denna bedömdes dock inte uppfylla de uppställda kraven. Därför gjorde man en utvärdering av på marknaden tillgängliga simulatorer. Valet föll på HILO som utvecklades av det engelska företaget GENRAD. HILO uppfyllde också kravet att det skulle vara en dynamisk simulator till skillnad mot TESTAID som var en statisk simulator. För att resultatet från en HILO simulering direkt skulle kunna användas tillsammans med VETO måste resultaten från HILO konverteras till VETO format. Detta löstes genom att ett konverteringsverktyg beställdes från GENRAD.