De två första autotestarna inköptes från det engelska företaget ELLIOTT och det amerikanska företaget HAC (Hughes Aircraft Company).
ELLIOTT-testaren, som var remsstyrd, saknade i princip operativsystem. Den hade funktioner för att läsa in kommandon från en hålremsa och sedan skicka det till något av testarens instrument. Mätresultaten kunde sedan läsas av och presenteras på en display. Hela testprogrammet låg på en hålremsa.
HAC-testaren var en mer avancerad testare. Den hade ett eget operativsystem som kunde exekvera ett testprogram i datorns minne.

LME Testare

Nästa testare som användes var en testare som införskaffades från LM Ericsson(LME). Vi är nu i slutet av 60 talet. Testaren var helt igenom specialutvecklad av LME. Hårdvara, Instrument och programvara var framtagna av LME. Datorn i testsystemet, med beteckningen UAC 1601, hade ett specialutvecklat operativsystem. Instrumenten styrdes av drivrutiner skrivna i ett assemblerspråk utvecklat av LME. Testprogrammen skrevs i ett av LME utvecklat högnivåspråk. Utvecklingen av testprogram och drivrutiner måste göras på ett stordatorsystem. Resultaten flyttades sedan över till testdatorn och man kunde börja utprovningen. När programmen skulle modifieras var man tvungen att flytta tillbaka programmet till stordatorsystemet för omkompilering och därefter flytta tillbaka resultatet till testsystemet. En mycket tidskrävande och omständlig process. Mindre ändringar kunde göras genom att maskinkoden modifierades direkt i testsystemet.

Val av nytt testarkoncept

I början av 1970 talet beslöt man sig för att satsa på ett nytt koncept. Valet stod mellan ett system från LM Ericsson (LME) och ett system från Hewlett Packard (HP).
LME offererade sin nya realtidsdator UAC 1610 med HERB som operativsystem. Namnet kommer från initialerna i namnen på några av utvecklarna (Hans, Erik, Rune och Bengt). Det var för sin tid en mycket modern dator med minnesskydd och möjlighet att samtidigt exekvera flera program. LME hade också tagit fram assemblator, länkare, FORTRAN kompilator och drivrutiner för yttre enheter.
HP offererade ett system som baserades på HP2116 datorn. HP tillverkade också instrument som var väl lämpade för uppgiften. Det operativsystem som ingick hette RSAF (Royal Swedish Airforce) och var specialutvecklat för svenska flygvapnet. Valet föll slutligen på HP beroende på att HP hade lämpligare instrument, större erfarenhet av test och en mer utprovad dator.

UAC 1610 användes sedan av LME inom projekt för process- och produktions-styrning. Den användes också inom telekomområdet och i vissa bankapplikationer.

Operativsystem i HP-testare

Tiden som HP Testare kom att användas blev drygt 20 år, en mycket lång tid. Därmed kom också ett flertal operativsystem att användas.

RSAF

Detta operativsystem användes till att börja med i A-nivå Testare. A-nivå testare var ett testsystem som var inbygda i en testbil. Vid användning kördes testbilen fram till flygplanet. På flygplanet fanns olika testuttag som testaren anslöts till.

Datorn i detta system, som för övrigt inte fick kallas dator utan benämndes instrument kontroller, hade beteckningen HP2116. Det var ett för test specialutvecklat operativsystem och med dagens mått tämligen rudimentärt. Det innehöll rutiner för att administrera filer på en skivenhet (T. ex. testprogram). Funktioner för att via en skrivare kommunicera med en operatör. Operativsystemet hanterade även en testpanel, som operatören använde för att kommunicera med testaren under test. Där fanns möjlighet att starta (RUN), stoppa (STOP) och fortsätta (FORTS) exekveringen av en test. Operativsystemet hade även funktioner för att kommunicera med remsläsare och stans.

Kommunikationen med instrumenten skedde via instrument drivers som var skrivna i HP Assembler. Framtagningen av drivrutinerna gjordes ursprungligen av HP men viss modifiering gjordes senare av CVA. Det behövdes i princip en rutin för varje instrument. RSAF systemet var absolutadresserat vilket innebar att det i koden måste anges till vilken adress rutinen skulle laddas när den lästes in från skivan. Detta var naturligtvis en felkälla som kunde resultera i många fel, och det gjorde det också.

För att assemblera (kompilera) drivrutinen till maskinkod användes en assemblator som utvecklats av HP.

Varje instrumentdriver måste också ges ett namn (T.ex MDVMU) och parametrarna som den anropades med, både typ och antal, måste beskrivas. Detta gjordes i två st. tabeller som kallades call och mnemonic tables.

Testprogrammen skrevs i språket BASIC (Beginners All Symbolic Instruction Code). Genom att anropa instrumentrutinerna enligt beskrivningar i call och mnemonic tables och använda de statements som fanns i BASIC var det nu möjligt att skriva program för automatisk test.

Operativsystemet hade funktioner att katalogisera (spara på skiva), "deleta" och "printa ut" tester (program).

Vid exekveringen av instrumentrutinerna hade man exakt kontroll på vad som hände. Inga avbrott eller andra saker var inblandade och det gick att få ett mycket snabbt och helt deterministiskt förlopp. Detta var mycket användbart eftersom en del instrument hade flera interfacekort och krävde noggrann timing.

TODS

Nästa operativsystem från HP hette TODS (Test Operating Disk System). Till skillnad mot RSAF var det relokerbart. TODS fanns i flera varianter De som användes vid CVA nämns nedan.

TODS-B

TODS-B användes framförallt i PPU (Program Produktions Utrustning) verksamheten. Här arkiverades program och leveranser förbereddes.

I ATS2 (mikrovågstestaren) användes ett operativsystem som var en hybrid mellan RSAF och TODS-B.

TODS-C

Omkring 1974 beslutades att autotest skulle införas på C-Nivå och det var analoga kretskort som skulle testas. Även nu köptes utrustningen från HP. Som operativsystem användes TODS-C. TODS-C var ett operativsystem specialdesignat för test. Det användes inte bara till system för svenska flygvapnet, utan ingick också i system som HP levererade till många andra kunder. Då TODS-C var ett relokerbart system medan RSAF var absolutadresserat måste det länkas innan det kunde laddas. Länkningen gjordes med en länkare som levererades av HP.

DOS

Från Singer Kearfott i New Jersey köptes i mitten av sjuttiotalet ett nyckelfärdigt testsystem för att testa enheterna i ett tröghetsnavigeringssystem, som utvecklats av Singer Kearfott. Systemet var baserat på HP konceptet, men skiljde sig på många punkter från tidigare HP System. Här användes DOS (Disk Operating System) som operativsystem. Testprogrammen skrevs i Singer Kearfott BASIC, som skiljde sig en del från de BASIC varianter som HP använde. Singer Kearfott hade också utvecklat hårdvara och mjukvara till en enhet som kallades RADMA (RAnDom Memory Acsess). Enheten användes för hantering av data från navigeringsrundor. Instrumentrutinerna skrevs i HP Assembler och var analogt med förfarandet för rena HP system.

Val av nytt operativsystem

År 1977 bestämde man att en större uppgradering av ATS1 skulle göras. Uppgraderingen innebar utbyte av hårdvara (Dator, Switchenhet mm), ett flertal instrument samt programvara. För val av operativsystem såg man 3 alternativ.

Första alternativet var att gå vidare med RSAF som hade visat sig ha goda egenskaper för instrumentstyrning. Det var snabbt och man kunde i det närmaste få en exakt kontroll av timing. Dessutom hade man stor erfarenhet av systemet och man kände väl till dess styrkor och svagheter.

Det andra alternativet var att välja TODS-C som var ett nyare system och speciellt lämpat för test. CVA hade ju också använt det i några system.

Det tredje alternativet var att välja RTE (Real Time Executive) som var ett multiuser realtidssystem. Av detta system hade CVA mycket liten erfarenhet.

Valet föll slutligen på RTE. Att man inte valde RSAF berodde framförallt på att det inte supportade den nya hårdvaran såsom nya skivenheter, minnen i datorerna större än 32K, kassettband, GPIB bussen mm. Operativsystemet supportades hellre inte längre av HP. Skulle vi ha valt RSAF hade vi själva fått göra all vidareutveckling.

TODS-C var ett nyare system, men även här hade HP för avsikt att inom en snar framtid sluta med supporten.

RTE

Så vad var nu RTE?

RTE var ett multiuser Realtids operativsystem som användes av HP i autotestsystem, men det användes även i många andra tillämpningar.

Med RTE kunde man använda den nya hårdvaran såsom skivenheter, minnen, disketter osv. Testprogrammen skrevs som tidigare i HP BASIC, visserligen inte helt kompatibel med RSAF BASIC. Den nya BASIC:en modifierades av CVA för att den skulle bli mera lik den som användes i ATS1.

Ett krav vid uppgraderingen var att testprogram framtagna för ATS1 skulle kunna användas i ATS10. Ett program för att konvertera testprogrammen från ATS1 till ATS10 togs fram och det fungerade över förväntan.

Instrumentrutinerna togs fram på ungefär samma sätt som tidigare. Det nya var att nu började FORTRAN 4 att användas som programspråk och framtagningen gick därför snabbare. Så småningom gick man över till FORTRAN 4X som var en utvidgning av FORTRAN 4 med bl a syntax som stödde strukturerad programmering.

Med RTE fick man nu för första gången möjlighet att lagra källkoder för instrumentrutiner och andra systemprogram i systemet. Tidigare sparades källkoderna på pappersremsa. Källkoder för BASIC-program gick att lagra tidigare.

RTE var ett realtidssystem och kunde hantera yttre händelser som t. ex. klock-tick och andra avbrott. Följden av detta blev att man inte längre kunde få den exakta timingen och snabbheten som man hade i RSAF systemet. Det fanns dock ett knep som man kunde använda sig av för att under en kortare tid stänga av avbrottssystemet. Genom att anropa rutinerna LIBR och LIBX kunde man manipulera med avbrottssystemet.

Ett stort steg framåt kom vid introduktionen av GPIB bussen som började användas omkring 1977. Nu fanns det helt plötsligt ett mycket enklare sätt att kommunicera med instrumenten. Det gällde både hårdvara och mjukvara. GPIB bussen var inte särskilt snabb, men i de flesta fall var det helt tillräckligt.

För att hantera minnen större än 32K och partitioner hade RTE ett Memory management System (MMS).

RTE hade också minnesskydd som innebar att en rutin inte kunde skriva sönder en annan rutin i systemet, något som var fullt möjligt tidigare.

I HP systemen fanns även möjlighet att mikroprogrammera.

RTE systemen fanns i många varianter. De system som CVA använde för autotest var RTE3, RTE4A och RTE4B.

RTE 3

RTE 3 var det första RTE-system som användes och en stor del av utvecklingen gjordes under detta system. RTE 3 systemen uppgraderades senare.

RTE 4A

RTE4A var en vidareutveckling av RTE3 och blev också slutprodukten i flera testare.

RTE4B
RTE4B var en vidareutveckling av RTE4A. Den största skillnaden var att RTE4B hade en Session Monitor som möjliggjorde att man kunde logga in som olika användare. Användarna kunde ges olika behörigheter.

RTE4B användes i de testare som togs fram i slutet av HP-eran.

Uppgradering av HP-systemen

I början av 1990-talet bestämde man sig för att byta ut 2645 bildskärmarna och 7906 skivenheterna eftersom reservdelar inte längre gick att få tag på.

Ersättare för skivenhet köptes från Bill Klauer Retrofit (BKR).

Utbyte av 2645 terminalerna löstes genom att ersätta den med en SUN Station. I SUN stationen emulerade man en 2645 terminal genom att med ett verktyg i SUN stationen skapa ett fönster där 2645 terminalens alla funktioner emulerades. SUN stationen utnyttjades också för att spara mätdata från en körning. Med SUN systemets betydligt större utbud av verktyg kunde sedan datat statiskt behandlas på ett mer avancerat sätt.

Omkring 1995 började man också använda sig av RUF data (Data från ett flygpass) i testaren som stöd vid felsökningen. Systemet som utvecklades för ATS10 kallades EOS.

Operativsystemet som användes i SUN hette SunOs och var SUN´s variant av UNIX.

SunOs

SunOs var SUN's variant av UNIX. SunOs hade också ett fönstersystem, X-Windows, som användes för att kommunicera med operatören. Med DevGuide, ett program för att skapa interface, kunde egna användarinterface skapas. Detta var mycket användbart när HP Terminaler skulle emulerades på en SUN station.

Systemprogramvaror

Assemblator

I de första system som levererades från HP användes i huvudsak assembler som systemprogramspråk. HP-datorerna hade en omfattande instruktionslista för att skriva assemblerprogram. För att översätta assemblerkod till maskinkod användes en assemblator som levererades av HP.

Fortran

I samband med övergången till RTE började man också att använda FORTRAN i allt högre grad för att utveckla systemprogram. Först användes FORTRAN 4, men sedan gick man över till FORTRAN 4X som var en utvidgning av FORTRAN 4 med bl. a. syntax som stödde strukturerad programmering. Programframtagningen gick nu snabbare eftersom programmen gjordes på en högre nivå och det fanns många användbara biblioteksfunktioner.
Vissa försök gjordes även att använda Pascal, men det slog aldrig igenom.

Mikroprogrammering

I HP-systemen fanns även möjlighet att mikroprogrammera. Med mikroprogrammering kunde man skapa nya instruktioner som direkt påverkade datorns interna bussar. Tanken var att detta verktyg skulle kunna komma till användning i tidskritiska applikationer. Det kom dock aldrig att användas i någon större omfattning.

GPIB Driver

Ett stort steg framåt kom vid introduktionen av GPIB-bussen som började användas omkring 1977. Nu fanns det helt plötsligt ett mycket enklare sätt att kommunicera med instrumenten. Det gällde både hårdvara och mjukvara. GPIB-bussen var inte särskilt snabb, men i de flesta fall var det helt tillräckligt. Detaljstyrningen av instrumentet gjordes i och med detta av en drivrutin som tillhandahölls av HP. GPIB-bussen kallades ursprungligen för ASCII-bussen, men namnet ändrades i och med att det blev en IEEE-standard.

Sysgen

För att generera ett RTE-system tillhandahöll HP ett speciellt program. Programmet använde en svarsfil som input. Denna fil innehöll en total beskrivning av hur systemet skulle se ut, d.v.s. I/O-kort och vilka drivrutiner som användes specificerades liksom hur minnet skulle användas. Enheter tilldelades logiska namn (LU). Massminnena (skivenheterna) konfigurerades till logiska enheter, där filer som hörde samman kunde lagras för att få en bättre struktur.

Switch

För att installera ett genererat system fanns ett program som hette ”Switch”. Input var den genererade filen som var resultatet från en körning med ”Sysgen”. Man sade att man ”switchade” system när ett nytt system installerades.

CMM(3/4)

Ett mycket användbart program i systemutvecklingen var CMM, CMM3 för RTE III system och CMM4 för RTE4 system. Officiellt stod CMM för Computer Memory Modification, men enligt rykten från HP var det en förkortning för Charles Mike Manley, en av förgrundsfigurerna vid utvecklingen av RTE systemen och den som tog fram CMM.
Med CMM var det möjligt att modifiera RTE-systemets tabeller, pekare och minnesinnehåll. Det var också möjligt att läsa ut de passwords, som användes för inloggning. I princip kunde vilken modifiering som helst göras.

Senast uppdaterad 2011-12-14

Systemprogramvara och operativsystem

RTE4B RTE4B var en vidareutveckling av RTE4A. Den största skillnaden var att RTE4B hade en Session Monitor som möjliggjorde att man kunde logga in som olika användare. Användarna kunde ges olika behörigheter.

RTE4B
RTE4B var en vidareutveckling av RTE4A. Den största skillnaden var att RTE4B hade en Session Monitor som möjliggjorde att man kunde logga in som olika användare. Användarna kunde ges olika behörigheter.