| ||||||||||||||||||
|
|
|
|
En sådan här pärm med speciella |
I början fanns inte så många krav, utan de krav som fanns var de som vi
själva ställt upp. I slutet av 70-talet kom krav på att programmen
skulle vara strukturerade.
Den metod som valdes kallades JSP (Jackson Structured Programming)
(Se utdrag ur TIFF 1982 nr 1 ). De personer som arbetade med
JSP utbildades för att kunna tillämpa
metoden.
Under 80-talet blev kvalitet ett modeord
(Se U-Aktuellt 1985 nr 13 Avsnittet "Programvaran är värd ett kapitel för sig").
NATO hade ett kvalitetssystem som kallades AQAP (Allied Quality Asurance Publication) populärt kallat AQAP-normerna.
De normer som var mest intressanta för oss var AQAP-1 som behandlade
hårdvara och AQAP-13 som behandlade mjukvara.
Under 90-talet ersattes AQAP normerna av ISO standarder. Det fanns
möjlighet att bli certifierad av ett oberoende institut vilket också
gjordes. Uppfylldes kraven fick man ett certifikat. Certifikatet måste
sedan förnyas varje år. Den standard som vi certifierades emot var ISO
9001 och behandlade i huvudsak mjukvara.
Det institut som utförde certifieringarna var DNV (De Norske Veritas)
Handhavande
Vid varje testare fanns en
handhavandebeskrivning som bl.a. beskrev hur systemet startades och
stängdes av samt olika sätt att logga in och ut. Beskrivningar av hur
och hur ofta självtesten skall köras.
Beskrivningar av hur uppdateringar av testprogram och systemprogramvaror
skall hanteras beskrivs här. Vidare fanns en instruktion som angav hur
kalibrering skulle gå till och hur ofta den skulle utföras. Dessutom
fanns en instruktion som specificerade hur testaren skulle kontrolleras
t.ex. visuell kontroll.
Då HP 2645
terminalerna ersattes av Sun stationer togs ett speciellt interface fram
för att simulera 2645 terminaler Se ATEWIN.
(På engelska)
Genom att använda ett program som hette ATELOG kunde erhållna mätvärden
tillsammans med utvärderinggränser sparas på en fil.
Dessa värden kunde sedan användas i ett system för mätvärdesanalys. Se
ATEMVA (På engelska). Tanken var att man snabbare skulle kunna lokalisera felet. På sikt
var tanken att kunna använda system för Artificiell Intelligens (AI) för
att underlätta felsökningen. Vissa försök gjordes också tillsammans med
ett israeliskt företag men det hela avbröts bl.a. av att det skulle bli
alldeles för dyrbart.
Basic Programmering
I princip var det BASIC som
användes för testprogrammering. Det fanns några undantag. T.ex. användes
ett av HP (Hewlett Packard) utvecklat språk för digitaltest. Andra
undantag var minnestest och komparatortest (Se
Testprogramspråk
i autotestare).
BASIC var på många sätt ett fantastiskt språk. Det var lätt att lära och
man slapp ifrån besvärliga moment som kompilering, länkning och
laddning. Det gick att provköra så fort det var inskrivet.
BASIC Manualer levererades av HP. Då det inte fanns något krav på att
den som utvecklade testprogrammen skulle kunna engelska översattes
manualerna till svenska.
BASIC utvecklades med tiden och det var stor skillnad mellan den BASIC
som användes i den första och sista. Kravet att översätta manualerna
till svenska försvann så småningom. Istället användes originalmanualerna
från HP.
Instruktioner för hur BASIC programmen skulle skrivas togs fram.
Så här skulle ett BASIC Program Ue-enheter struktureras (Se
Anvisning för
ATE10 Testprogrammering)
Notera numreringen av de fasta positionerna i dokumentet!
Testprogram för Sue enheter skulle utformas så här (Se
ATS 6/11/12 Testprogrammering).
Subrutinanrop
För att förenkla för de som utvecklade testprogram infördes möjligheten att anropa externa subrutiner. Det gjordes genom att BASIC kompletterades med ”call” och ”Mnemonics Table” (Se ATS 6/11/12 Subrutinanrop).
Med detta tillägg
kunde den som utvecklade testprogram på ett enkelt sätt kommunicera med
testsystemets instrument. Man behövde inte fundera på hur den
detaljerade instrumentstyrningen skulle gå till, som i vissa fall kunde
vara ganska knepig.
När sedan HP introducerade sin IB Bus (GP-IB) förenklades hanteringen
alldeles enormt.
Så här kunde en uppställning av en DVM (Digital Voltmeter) se ut:
CALL MDVMU (Par1, Par2, Par3, Par4, Par5)
Par 1 = Mätfunktion
Par 2 = Mätområde
Par 3 = Filter
Par 4 = Integrationstid
Par 5 = Ingång
Sammanställning av anrop
som fanns i system för analog och digitaltest
(Se BASIC Anrop
ATS6/11/12).
Med tiden blev instrumenten alltmer komplicerade och det blev mer och
mer komplicerat att konstruera Calls och Mnemonics. Ta till exempel
moderna mikrovågsinstrument såsom spektrumanalysatorer, fasbrusmätare
och nätverksanlysatorer som kunde programmeras för kanske tusentals
funktioner. Att styra alla dessa funktioner med call och Mnemonics
skulle rent teoretiskt vara möjligt men i praktiken helt ogenomförbart.
Därför infördes en metod som gick under namnet strängprogrammering.
Den bestod av 2 st. anrop. Ett för att skicka kommandon till
instrumentet och ett för att läsa från instrumentet.
För att skicka kommandon till instrumentet:
Call WriteBus(Lu, ”Kommandosträng”)
Lu = Logiskt nummer för aktuellt instrument
Kommandosträng = Sträng med kommandon som skall skickas till instrumentet
För att läsa från instrumentet
Call ReadBus (Lu, Variabel)
Lu = Logiskt nummer för aktuellt instrument
Variabel = Variabel där det utlästa värdet placeras
Strängprogrammering användes i de fall då det inte gick att utföra en önskad funktion med Call och Mnemonics.
PPU verksamheten
För att stödja framtagningen av programvara inrättades en ny avdelning. Avdelningen kallades PPU-avdelningen och hade 4-5 medarbetare. Deras uppgift var att fungera som stöd vid framtagning av programvara och sköta leveranser till B-Nivå (Flottiljer) och C-Nivå (Centrala verkstäderna). Här följer en beskrivning av några av de arbetsuppgifter som PPU-avdelningen hade.
Föra över program från underlag till hålremsa
Till att börja med skrevs
alla systemprogramvaror i assembler (T.ex. drivrutiner för instrument).
Underlagen överlämnades sedan till PPU-avdelningen som stansade in det
på en hålremsa och man fick något som kallades källkod. Hålremsan
assemblerades och i bästa fall fick man en hålremsa med binärkod som
kunde läsas in i datorn. I det flesta fall resulterade det i ett antal
assembleringsfel som måste åtgärdas. Rättningen gjordes genom att remsan
med källkod måste stansas om med felen åtgärdade. Sedan var det dags för
en ny assemblering som förhoppningsvis var felfri. Annars fick
proceduren upprepas tills en felfri assemblering erhållits. Anledningen
till att man gick över remsa var att de tidigaste systemen, de som hade
RSAF och TODS som operativsystem inte kunde hantera ASCII kod och
systemprogrammen hade ju en källkod i ASCII.
|
|
|
En typisk hålremsa |
Det fanns också en möjlighet att för hand stansa kortare remsnuttar. Av
praktiska skäl var det endast användbart i de första systemen där
assembler användes som systemprogramspråk.
|
|
|
Handstans för att producera kortare programsnuttar |
För att rulla upp hålremsorna som i vissa fall kunde var väldigt långa
fanns en praktisk remsspolare som var väldigt användbar.
 |
 |
|
Remsspolare m/större |
Remsspolare m/mindre |
Föra över testprogram till skiva
Testprogrammen skrevs i BASIC, i alla fall i början. Här kunde programmen skrivas in direkt på en skiva eftersom det inte var ASCII som lagrades utan något som kallades ”Semi compiled form”. I och med att RTE som operativsystem började användas kom man bort från remshanteringen. RTE kunde lagra källkod på skivor.
Uppdatering av masterskivor
Det fanns två typer av
masterskivor, dels skivor med testprogram (objektmaster), dels en skiva
med systemprogram (systemmaster). Programmen (Testprogram och
Systemprogram) utvecklades hela tiden och när det fanns en tillräckligt
stor mängd ändringar eller nyproducerat var det dags att uppdatera
mastrarna. Det fanns två masterserier. En för testprogram och en för
systemprogram. Varje serie bestod av fyra skivor. Uppdateringen gick
till på så vis att det som skulle läggas in på mastern kopierades till
den äldsta av skivorna, som nu blev den nyaste. På så vis fick man en
roterande backup bestående av de senaste fyra utgåvorna. Blanketter för
att utföra ändringarna togs fram. (Se
Rutin för ändringar).
 |
|
Bild på en 7906 skiva |
Göra i ordning produktionsskivor och skivor för systemprogram
Från PPU-avdelningen fanns
möjlighet att beställa skivor för testprogram och systemprogram. För att
beställa dessa skivor fanns speciella blanketter framtagna.
Personal på PPU avdelningen gjorde då i ordning den beställda skivan.
Arbetet bestod i att kopiera senaste masterskivan till en tom skiva som
sedan levererades till aktuell testare.
Flyttning av enstaka filer mellan system
För att flytta mindre filer
mellan hp system med 2640 terminaler var minikasetterna till stor hjälp.
|
|
|
Minikasett |
Sådana här minikasetter användes för att flytta mindre filer mellan system. Man kan säga att de motsvarade USB-minnen som kom långt senare. Naturligtvis kunde de inte mäta sig med USB-minnenas lagringskapacitet.
Leverera skivor till testare
Leveransen av objektskivor till testare sköttes vanligtvis av någon objekthandläggare som också verifierade att den nya skivan fungerade. Leverans av nya systemprogram gjordes vanligtvis av ATE ansvarige för systemet i fråga. Nya systemet installerades och verifierades att det fungerade. Ett vanligt sätt att verifiera var att köra självtesten som då skulle gå igenom utan några fel.
Hantera inköpt källkod och programvaror
Det fanns ett krav på att
vi själva skulle ha tillgång till all källkod för samtliga programvaror
som ingick i systemet. Beslutet grundades på att i händelse av krig
kunde Sverige bli blockerat och i sådant fall skulle vi själva kunna
underhålla och vidareutveckla systemen. Källkoder från HP levererades på
magnetband och skivor.
Källkoder som levererades på magnetband måste hela tiden underhållas.
Underhållet bestod av att magnetbanden med jämna mellanrum spolades om.
|
|
|
Ungefär så här såg magnetbanden som användes ut |
På skivorna fanns programvaror för att underhålla programvarorna och
genera nya system.
För att kunna sköta dessa arbetsuppgifter hade man ett antal
utrustningar till sitt förfogande. De kallades PPU utrustningar. T.ex
PPU 1 för arbeten till ATS1
|
|
|
Så här såg ett typiskt PPU-system ut |
Beställning av jobb
För att beställa arbete från PPU-avdelningen hade ett antal blanketter tagits fram. Gällde det att få en hålremsa stansad så fanns en blankett för det. Gällde det att uppdatera produktionsmastern fanns blanketter för det (se uppdatering av produktionsmaster) eller om man ville ha en ny produktionsskiva fanns också speciella blanketter. (Se ATS 6/11/12 Beställning av PPU-arbeten).
Felrapportering
För att rapportera fel i
systemet fanns ett system för felrapportering. Blanketter fanns där
felet kunde beskrivas. Det gick också att lämna förslag på
förbättringar.
I ett dokument kallat PVA-nytt beskrevs nyheter i en ny systemleverans.
ATE-möten
ATE-möten hölls regelbundet omkring 2 ggr/år. Här diskuterades testarnas status. Det kunde vara om aktuella felrapporter eller problem med något instrument.
Adapterframtagning
Hur adaptrar skulle
konstrueras och dokumenteras var noga uppstyrt. Framtagningen av
adaptrar skilde sig från system till system så här såg det ut för ATS10.
(Se ATS10 Korskopplingsunderlag).
I varje adapter skulle en unik kod finnas som kunde avläsas av
testprogrammet som på så vis kunde verifiera att rätt adapter monterats.
Under en tid då framtagningen av testutrustningar var som mest intensiv
fanns en särskild avdelning som tillverkade adaptrar.
Dokumentation av testprogram
Att dokumentera
testprogrammen var en viktig del av arbetet.
Testare för Ue-enheter som tex. ATS10 hade huvudsakligen testprogram
skrivna i BASIC medan testare för Sue-enheter hade program som var en
blandning av BASIC och program specialdesignade för digitaltest.
Testprogram för Sue-test skulle dokumenteras så här: Se Dokumentation av testprogram.
Testtoleranser
Ett omfattande system för
hantering av TestTOLeranser (TTOL) togs fram.
Testtoleranser erhölls från objekttillverkarna. Vid test av objekt som
under flygningen fått en felindikering kunde det ofta vara så att
objektet vid test i autotestare passerade utan anmärkning. Detta
kallades för UA-Glappet (Utan Anmärkning Glappet) och var ett stort
problem.
(Se utdrag ur TIFF 1986 nr 1).
Verktyget TTOL var tänkt att användas som ett
hjälpmedel för att studera hur olika objekt rent signalmässigt passade
ihop.
PVA för Jas
Under 80-talet började man
titta på en ersättare till PVA-systemet som skulle användas i
39-Systemet (JAS). Systemet fick namnet GRAAF och ambitionsnivån var
hög. Antagligen alldeles för hög. GRAAF fick aldrig något större
genomslag och fick aldrig samma betydelse som PVA-Systemet.