Bakgrund
När jag som ung flygingenjör (egentligen flygunderingenjör, som förkortades "fundering")
kom från Centrala flygverkstaden i Arboga till Kungl flygförvaltningen, sedermera en del
av försvarets matrielverk, möttes jag av det komplexa C3I-system som kallades Stril 60.
Redan första anställningsdagen, den 31 mars, var alla berörda
vid dåvarande luftbevakningsbyrån inbjudna till Standard Radio &
Telefon AB i deras nya byggnad i Barkarby för att se på en Fabriksuppkoppling
av databehandlings- och presentationsdelen för flygvapnets
radargruppcentraler (rgc) innan den levererades för installation
i den första anläggningen. På skolbänken under flygingenjörsutbildningen
hade vi lärt oss exotiska benämningar på olika befattningar,
rrjal, målobs, höjop, lvled etc, och deras huvudsakliga arbetsuppgifter
hade mycket noggrant blivit inpräntade hos oss.
(Man hade till och med skriftliga prov på sådant!)
SRT, dvs Standard Radio och Telefon AB, sedermera Stansaab,
ytterligare sedermera Datasaab, därefter i tur och ordning SRA,
Ericsson Radio Systems, Ericsson Radar Systems, Ericsson Radar
Electronics (jag hoppas att jag inte glömt en anhalt i Ericsson-
resan), Bofors Electronics och nu slutligen (?) NobelTech, hade då
åstadkommit något som på den tiden var enastående.
Bl a kunde man på en och samma indikator visa "rå" och
"korrelerad" radarbild samtidigt med "syntetisk" information
såsom text, symboler, karta och avståndsvektorer m m. Dessutom
kunde man på en och samma indikator presentera radarbild från
olika radarstationer samtidigt. För att rita den syntetiska bilden
utnyttjade man tiden mellan radarsvepen. Att rita en bokstav var
inte så enkelt. För varje bokstavstyp (och även för varje annan typ
av symbol) fordrades ett särskilt kretskort för att styra katodstrålens
avlänkning. Och detta naturligtvis i varje indikatorenhet! Jag kan
försäkra att det fanns mycken och skrymmande elektronik i rgc.
På den tiden uppfattade man emellertid inte detta uppbåd av
utrustning som skrymmande; ville utföra funktioner som var
komplicerade och ville man kunna styra avancerade förlopp på ett
enkelt sätt, fordrades det självklart mycket elektronik. När vi först
fick se denna utrustning och fick en sakkunnig genomgång av vad
den förmådde, var vi närmast begeistrade över att den inte tog
större utrymmme i anspråk. Man slapp ju en massa elektronrör. Här
hade den nva tekniken med transistorer verkligen på ett framträdande
sätt minskat utrymmesbehovet - kanske med en faktor tio!
Även om presentationssystemet med sin bakomliggande
datamaskin (datorer kallades så då) troligen var det modernaste i
världen, var det något annat som fascinerade mig mer - något som
jag inte direkt tänkte på vid min första konfrontation med rgc -
nämligen det omfattande systemarbete som legat bakom hela Stril
60. Detta stod klart för mig, när jag efter några veckor hade haft
arbetsuppgiften att sätta mig in i rgc gränsytor mot yttervärlden och
därefter lärt mig något om lfc luftförsvarscentral), som var
överordnad rgc.
Till rgc var flera låghöjdsspaningsradarstationer anslutna med
bredbandslänkar. Man hade som mest 7,5 MHz till förfogande i
varje länkhopp, vill jag minnas, men ofta var bandbredden mindre.
Från varje radarstation överfördes normalt två videokanaler för
radarbild och ett antal smalbandskanaler, bl a för bäringsinformation.
I rgc behandlades radarinformationen på olika sätt för att kunna
ligga till grund för upptäckt och följning av mål och för stridsledning.
Behandlad information om följda mål sändes också över till lfc på
smalbandskanaler. En smalbandskanal tillät signaleringshastigheten
1200 baud, Större bandbredd kunde inte garanteras!
I lfc skedde den överordnade ledningen av sektorns taktiska
verksamhet. Ledningen grundades på luftlägesinformation, dels
från rgc dels också från höghöjdsradarstationer, som var direkt
bredbandsmässigt anslutna till lfc, och på rapporter om tillgängliga
resurser på sektorns olika flygbaser. Även i lfc skedde datorstödd
målföljning, och i såväl lfc som rgc kunde man med stöd av
stridsledningsprogram leda jaktflygplan med hjälp av både tal- och
dataradio. Härutöver i Stril 60 ledningscentraler hade man
avancerade hjälpmedel för analys av flygföretags sammansättning
och identtifiering, radiopejl- och störpejlfunktioner, samverkan
med olika robotförband med hjälp av datautbyte och samverkan
med luftvärnet samt i vissa centraler samverkan med marinen och
civil flygtrafikledning. Dessutom svarade särskilda befattningshavare
för luftförsvarsorientring och alarmering. Som komplement till
den radarinformationsbaserade luftlägesbilden fanns den optiska
lutftbevakningen, som från sina luftbevakningstorn via lgc
(luftförsvarsgruppcentral) rapporterade med tal (sedermera med data)
till lfc och rgc. I reservfall kunde stridsledning ske från operatörs-
platser vid radarstationerna. Det tekniskt revolutionerande med
Stril 60 var naturligtvis att man utnyttjade digital- och datateknik
varhelst det var möjligt.
Jag har här beskrivit en del av Stril 60 i imperfekt, vilket inte är
helt relevant, eftersom de allra flesta av de funktioner som sålunda
introducerades för c:a 27 år sedan fortfarande utnyttjas och en stor
del av den ursprungliga materielen fortfarande är i bruk.
Beskrivningen skulle emellertid i vissa avseenden varit felaktig och
framför allt ofullständigare om jag hade använt presens. Många
funktioner har tillkommit och framför allt förbättrats, och suffixet
60, som angav modernitet under 50- och 60-talen, är inte längre
relevant.
Läsaren må fråga efter ändamålet med denna historieskrivning,
och svaret blir då att jag vill använda Stril 60 som exempel på ett
stort C3I-system som svenska försvaret anskaffat. Dessutom kan
man därmed belysa innebörden av några moderna uttryck som
nyttjas när man anskaffar stora system. Evolutionär utveckling och
inkrementell anskaffning är exempel på sådana utttryck. Andra begrepp,
som inte är så modetyngda, är infrastruktur och återanvändning. Det
första ordet, infrastruktur, användes knappast i informationsteknlologiska
sammanhang under 60-talet men däremot ofta i den
politiska och ekonomiska världen. Framför allt visar dock Stril 60
hur väsentligt det är med övergripande systemarbete och samordning
för att man skall nå avsett resultat.
Kravbildens förändring
För närvarande upplever vi en teknisk utveckling med en takt som
mänskligheten hittills inte skådat, vilket är särskilt accentuerat inom
informationsteknologiområdet. Utvecklingen har dessutom vissa
indirekta effekter, nämligen att vi blivit nonchalanta gentemot de
fördelar den innebär och även inobservanta för de nackdelar den
medför. Den första effekten kan karakteriseras med uttrycket
"möjligheter skapar krav". Den andra effekten är inte lika lätt att
samnmanfatta i en ordvändning, men den ger sig tillkänna i att man
förlitar sig alltför mycket på tekniken: när denna inte motsvarar
föräntningarna, blir man " ställd".
Att möjligheter skapar krav är i och för sig inget negativt. Det är
förmodligen utvecklingens drivfjäder. För tjugofem år sedan var
det ingen som drömde om att på skrivbordet (än mindre i knät) ha
en dator med minneskapacitet och snabbhet som vida överskrider
den tidens stordatorer, vilka upptog ett helt rum och hade ett
effektbehov på ibland tiotals kilowatt. Inte ens specialisternas
tekniska prognoser förutsåg denna utveckling, än mindre planerade
man för att kunna skaffa sådana system inom en rimlig framtid.
Motsvarande gäller för hela C3I-området. Radarteknik och ny
sensorteknik, kommunikationsteknik och presentationsteknik
utvecklas raskt, och de landvinningar man gör inom dessa områden
kan utnyttjas mycket tack vare de prestanda och den miniatyrisering
som modern datateknik erbjuder. Numera finns det också
utvecklingshjälpmedel för datorbaserade system, som förkortar
tiden mellan idé och förverkligande. Dessa hjälpmedel har dock i
de flesta fall inte utvecklats i samma takt som maskinvaran.
Utvecklingen har givit nya möjligheter, som inneburit att
kravställarna vågat höja sin ambitionsnivå, vilket i sin tur uppmuntrat
forskning och utveckling, som resulterat i ytterligare bättre
möjligheter och så vidare i en " evig" kretsgång, dvs möjligheter skapar
krav. Vi ändrar helt enkelt vår referens till vad som är godtagbart.
Om man blickar bakåt kan man lätt konstatera att kravbilden nu är
mycket strängare än den som var vanlig För bara tio år sedan, och
det gäller alla aspekter på funktioner, system, utrustningar,
handhavande, tillgänglighet etc.
Vi måste vara medvetna om att vi befinner oss i denna kretsgång,
när vi ställer våra krav. Ett C3I-system är dyrt, därför vill vi använda
det länge, Dessutom är det komplicerat och går i allmänhet inte att
köpa "från hyllan". Det levereras kanske flera år efter beställning
och skall sedan användas i minst 15 år. Redan under tiden från
specificering till leverans har möjligheterna (och alltså vår referens
till vad som är godtagbatt) ändrats så mycket att vi i vissa avseenden
tycker att vårt nylevererade system är litet gammalmodigt.
Betänk följande fingerade exempel: Låt oss säga att vi för åtta år
sedan specificerade ett litet datorsystem som skulle kunna användas
för ordbehandling, kalkyl och enklare register etc. 1983 var ABC
800 en toppmodern persondator som klarade av detta och mycket
till. Dessutom var den snabb jämförd med andra liknande datorer.
Enligt samstämmliga uppgifter från andra användare var detta en
dator man kunde "växa i". Vår specifikation passar alltså in på en
dator som ABC 800, och då har vi ändå överdrivit våra verkliga
krav för att ha något att växa i. 1991 levereras vårt lilla datorsystem
(åtta år är ungefär den tid som förflyter mellan specifikation och
leverans av ett stort C3I-system) som är en ABC 800. Den uppfyller
specifikationen med råge, men vi tycker den är gammalmodig.
Man styr den med underliga kommandon, det finns inte ens en
särskild symlbol för pekare, än mindre någon mus. Fönsterhantering
finns ej, totala lagringsutrymmet är vad som ryms på en diskett (det
andra är upptaget av systemprogram) och den "fasta disken" utgörs
av halvledarminnen om 0,5 MB. Vill man "växa", kan man köpa
till ytterligare 0,5 MB! När vi sedan jämför den med vår sekreterares
ganska nya utrustning som är en PC eller MAC, med 40MB
hårddisk och 386-processor med 2 MB internminne, med Windows
och mus och som dessutom är ansluten till en laserskrivare, tycker
vi sannolikt att vår nylevererade utrustning är "töntig".
Vår referens till vad som är godtagbart kommer alltså att förändras
drastiskt under de år som förflyter mellan speci6kation och
leverans av ett stort, komplicerat system.
Inkrementell anskaffning
Stril 60 kunde man av naturliga skäl inte anskaffa i en omgång. Dels
tillät inte budgeten det, dels fanns det helt enkelt inte i Sverige
tillräckligt med personal som hade rätt utbildning och erfarenhet
inom området. Utan att begreppet då hade myntats tillämpade man
inkrementell anskaffning, d v s man anskaffade Stril 60 bit för bit -
ganska stora bitar, emellertid. Detta var planerat att ske under c:a
tio år, men det tog av ekononliska skäl några år till, innan full
utbyggnad hade skett. (Med full utbyggnad menar jag att ursprung-
ligen specificerad och planerad funktionalitet och kapacitet upp-
nåtts.)
Vid inkrementell anskaffning bygger man upp systemet enligt en
plan så att funktionalitet och/eller kapacitet stegvis ökar. Varje steg
blir en avslutad affär mellan köpare och säljare. I varje steg kan man
naturligtvis tillgodogöra sig den tekniska utvecklingen vad avser de
nya delar som fogas till systemet.
I Stril 60 karaktäriserades den inkrementella anskaffningen
främst av att nya typer av radarstationer tillkom (och fortfarande
tillkommer). Dessa orsakade också de stora investeringarna. Men
även mindre tillskott till C3I-systemet uppenbarade sig i vissa steg,
t ex radiopejlfunktion, störpejlfunktion, stridsledningsfunktion för
JA 37 etc. Kapaciteten byggdes också ut i steg genom att anläggningarna
färdigställdes enligt en tidplan som löpte under många år.
Evolutionär utveckling
Oberoende av den inkrementella utökningen av Stril 60
funktionalitet och kapacitet skedde också en förändring som endast
berodde på den tekniska utvecklingen, främst inom datateknikområdet.
Jag avser här den nästan kontinuerliga förbättringen i lfc
och rgc av datorstödda funktioner genom utbyte av datorer och
progranlvara och kanske framför allt genom att man ersatte
digitaltekniklösningar med funktioner i datorprogram. Här
utnyttjade man de ökande möjligheter, som utvecklingen erbjöd,
och som man inte kunde ställa krav på vid den ursprungliga
anskaffningen helt enkelt beroende på att man då inte kunde
föreställa sig dem. Det var en evolutionär utveckling, fast det visste vi
nog inte om, ty begreppet existerade inte då!
Vid evolutionär utveckling, som begreppet tolkas idag, tillgodogör
man sig teknikens framsteg och egna vunna erfarenheter under
projektets gång. Det innebär att man i beställningen specificerar
sina krav på en hög nivå, och medveten om att nya möjligheter
uppstår - eller, noga räknat, omedveten om vad framtiden bär i sitt
sköte - ger viss frihet åt leverantören att producera en lösning inom
kravramen. Det sålunda erhållna grundsystemet uppfyller ett visst
(specificerat) mått av funktionalitet och kapacitet etc, men framför
allt är det utbyggbart och förändringsbart. Detta är det första steget.
De följande stegen, som oftast är flera, innebär att man rättar till de
missförstånd som uppstått vid tolkning av kraven, att man förändrar
och utökar funktionerna samt att man eventuellt byter ut eller
tillfogar ny maskskinvara, allt med utnyttjande av de möjligheter som
tekniken just då erbjuder. Förändringarna och utökningarna kan
också vara orsakade av förändringar i miljön eller i den verksamhet
systemet skall stödja. Med evolutionär urveckling blir systemet i
regel aldrig färdigt, vilket kan låta cyniskt, med det är just det
tillståndet som är det fina i kråksången! Man har redan från bödan
gått in för öppenhet mot förändringar orsakade av såväl
verksamhetskrav som den tekniska utvecklingen, och utnyttjar
man denna öppenhet rätt, får man ett system som aldrig blir
gammalmodigt! Emellertid blir man oftast bunden vid ursprungsleverantören,
ett förhållande som har både för- och nackdelar.
Infrastruktur
Parallellt med den inkrementella anskaffningen och den evolutionära
utvecklingen av Stril 60 skedde en behovspåverkad utbyggnad av
kommunikationsnätet som betjänade systemet. Denna utbyggnad
var sannerligen både inkrementell och evolutionär, men den
utfördes på ett annat sätt och grundade sig på behov hos många
intressenter, inte bara Stril 60. Kommunikationsnätet och de fasta
anläggningarna blev grunden till den tekniska infrastruktur som
försvaret byggde upp. Under hela framväxten av Stril 60 kunde vi
kommunicera enligt planerna. Så snart en yttre infömlationskälla
tillkomm, fanns det möjligheter till kommunikation med centralerna,
och när en flygbas färdigställdes var sambandsmöjlighetema säkrade.
(Detta är litet överdrivet.) Naturligtvis uppstod ibland förseningar,
men i stort är påståendet sant.) Dessutom utvecklades transmissionstekniken
och man införde tekniska förbättringar i takt därmed.
Som exempel kan nämnas, att på de kanaler, normalt vanliga
telefonkanaler, där vi överförde datameddelanden med en hastighet
av 1200 baud - ibland på särskilt fasutjämnade och inmätta kanaler
24OO baud - kunde man plötsligt överföra 9600 bit/sekund tack
vare en nv modulationsmetod. Som den ansvarige ingenjören
Earl-Edvard Eriksson på telebyrån ungefär uttryckte det: "Nu har vi
skaffat grejer, som gör att vi kan köra 9,6 kilobit på taggtråd!" Detta
är ett exempel på hur modernisering av infrastrukturen (i detta fall
kommunikationsnätet) kommer alla dess användare till nytta.
Ett annat exempel är att, när man i slutet av 60-talet hade löst
problemet att göra tillräckligt god extraktion av s k plottar vid
radarstationerna och omvandla radarbilden till en datasträng av
koordinater, man kunde överföra denna sträng i datameddelanden
från radarstationerna till centralerna i stället för att överföra hela
radarbilden. Nu räckte det plötsligt med smalbandskanaler i stället
för bredbandskanaler. Kommunikationsnätet var väl utbyggt med
smalbandskanaler, och radarbilderna kunde tack vare detta
distribueras till praktiskt taget vilken central som helst i Sverige,
vilket innebar stora fördelar. Dessutom friställdes många dyrbara
bredbandskanaler, som härigenom kunde utnyttjas för andra
ändamål.
I begreppet infrastruktur kan man inrymma mycket mer än
påtagliga delar som kommunikationsnät och anläggningar etc.
Infrastrukturen kan sägas innehålla allt det grundläggande, som vi
bygger vår verksamhet på, sådant som utnyttjas av många användare
oavsett tillämpningarna. En informationsteknisk infrastruktur kan
t ex bestå av kommmunikationsnät, datorer, operativsystem, databaser
m fl påtagliga delar, men också av generella hjälpmedel, såsom
utvecklingssystem, metodik, utbildning m m. Om man bygger upp
en bra infrastruktur som moderniseras i takt med utvecklingen, får
man en god grund för alla dess nyttjare i och med att infrastrukturen
erbjuder lösningar på de flesta gemensamma problemen. När man
utvecklar nya tillämpningar (system) behöver man därför inte börja
om från början, utan man kan bygga dem på infrastrukturen, som
ger de flesta grundläggande funktionema som tjänster, och i stället
koncentrera sig på sina speciella tillämpningar. Dessutom är
infrastrukturen en förutsättning för effektiv samverkan mellan olika
tillämpningar,
Den tekniska utvecklingen påverkar både infrastrukturen och
tillämpningsmöjligheterna. Behoven genererar krav på nya
tillämpningar (funktioner) men också krav på högre prestanda
(noggrannhet, uppdateringsintervall, kapacitet etc) och tillgänglig-
het. Med en god infrastruktur, som oberoende av behovsbilden
moderniseras när tekniken så medger, kommer automatiskt en stor
del av de förbättringar, som högre prestanda och tillgänglighet
innebär, att kunna tillgodogöras av existerande funktioner. När
man inför nya tillämpningar (nya funktioner) som bygger på
infrastrukturen, kolmmer även dessa att dra nytta av infrastukturens
förnyelse.
Återanvändning
I Stril 60 centraler fanns förhållandevis litet av konstruktioner
(design) och programvara som kunde återanvändas i senare
modifieringar eller utbyggnader. Undantag var viss maskinvara,
särskilt för kommunikation, och vissa programmerade funktioner,
t ex målföljningsalgoritmer. Till att börja med hade lfc och rgc olika
datorsystem med skilda programspråk; om ett programpaket skulle
flyttas från rgc till lfc, var man tvungen att programmera om det
(konvertering). Med tiden fick de båda centraltyperna delvis
datorer av samma slag, vilket i hög grad möjliggjorde utnyttjande
av gemensamt utvecklad programvara. Stril 60 var ganska ensamt
i sitt slag, varför det egentligen inte på något annat ställe fanns redan
utvecklade funktioner som kunde återanvändas vid uppbyggnad av
våra centraler.Jag kan däremot föreställa mig att leverantören av rgc
kunde återanvända en hel del rgc-program i centraler för flygtrafikledning,
som i många avseenden byggde på rgc-lösningar.
Idag är situationen helt annorlunda. Man har under årens lopp
utvecklat många avancerade funktioner som återfinns i flera olika
tillämpningar. Redan i datateknikens barndom tog man fram
algoritmer för numeriska beräkningar, statistik, sortering etc och
slog ihop dem till paket, som envar kunde skaffa sig och använda
i snart sagt alla typer av datorsystem. Sedan länge finns också hela
programpaket på marknaden för sammansatta funktioner i sådana
tillämpningar där marknaden är öppen, t ex ekonomi, planering,
kontorsarbete m fl. När det gäller mer speciella tillämpningar har
marknaden naturligtvis inte varit så stor och ofta inte öppen,
eftersom programvara så uttalat innehåller mycket av konstruktörens
och därmed företagets know-how.
I några moderna svenska stridsledningssystem har man emellertid
kunnat återanvända programvara.Jag tänker då på att NobelTech
i utvecklingen av StriC använder programvara som tidigare utveckiats
för strids- och eldledningssystem ombord på kustkorvetter typ
Göteborg. (StriC är benämningen på det senaste inkrementet i
utbyggnaden av strilsystemets centraler. StriC skall i stora drag
ersätta den uppgift som rgc nu har och erbjuder därutöver en hel
del nya och förfinade funktioner.)
Återanvändningen har varit möjlig beroende på att man i de två
systemen använder samma programspråk, och det underlättar
naturligtvis väsentligt att det är samma företag som står för
utvecklingen av de båda systemen. Programspråket är Ada, som
egentligen förtjänar en separat uppsats i dessa sammanhang.Jag skall
här bara nämna en egenskap hos Ada, som gör att program skrivna
i detta språk blir synnerligen lämpliga för återanvändning. En
programmodul i Ada kallas paket. Varje sådant paket består av två
delar, specifikation och kropp, båda delarna skrivna i Ada. Det fina
är, att specifikationen beskriver vad som skall utföras i paketet,
medan kroppen är programmet som anger hur det skall utföras.
Programtexten i specifikationen kan också kompletteras med
kommentarer som anger paketets prestanda. Här finns en möjlighet
för den som vill dölja sina fabrikshemligheter, att för en utomstående
kund bara visa specifikationema, vilket är tillräckligt för att kunden
skall kunna avgöra om han kan använda paketen i sin systemutveckling.
Man kan faktiskt bygga upp en modell av ett helt system
bara med hjälp av sådana Ada-specifikationer (ungefär som tidigare
blockscheman), kompilera den och därigenom se om strukturen
blir riktig.
Systemarbete och samordning
Nu konmmerjag äntligen till den verksamhet, som jag tror var det
väsentligaste för att skapandet och uppbyggnaden av Stril 60 skulle
lyckas. Resultatet beror enligt min mening på två fundamenta,
nämligen strilsystemets överblickbarhet och den lyckade ansvarsfördelningen
(egentligen "arbetsfördelningen") mellan och inom
organisationer. Mellan dessa begrepp rådde ett slags symbios.
Överblickbarheten gjorde att det var lätt att tekniskt dela upp
systemet i delsystem, såsom radarstationer, transmission, radio,
databehandling och presentation etc, och det var aldrig något tvivel
om vilken organisationsenhet som skulle arbeta med vad. De
funktioner strilsystemet understödde sträckte sig i allmänhet över
flera delsystem. Man införde begreppet funktionskedjor och tack
vare överblickbarheten var dessa lätta att urskilja och definiera.
Målföjningsfunktionen, t ex, (förrenklat beskriven) började i radarstationen,
fortsatte sedan via transmission till en korrelator och
digitalisering i centralen, där den gick vidare in i målföljningsdatorn
och presentationssystemet och utnyttjade därigenom nästan
alla typer av delsystem.
Vem skulle ansvara för funktionskedjorna? Det var ju i alla fall
dem användaren direkt utnyttjade. Ett brott i en sådan kedja skulle
äventyra hela funktionen! För att klara av detta inrättade man en särskild
systemsektion och senare en systersektion för systemkontroll
och -utprovning (tillsammans blev de senare systembyrån). detta
var mycket förnuftigt gjort. Nu fick man en organisationsenhet
som svarade för att de önskade funktionerna kunde erhållas. detta
gjorde att man kunde "översätta" de funktionella kraven till
tekniska krav på varje berört delsystem inklusive specifikation av
gränsytor mellan delsystemen. En mycket värdefull bieffekt av
detta var att man hela tiden bevarade överblickbarheten. På
motsvarande sätt gjorde man systemkontroll och -utprovning
funktionsvis tvärs över delsystemgränserna. Så småningom, när
centralena under sin evolutionära utveckling allt mer datoriserades
och stora delar av funktioneran sögs in i datorernas programkomplex,
kunde man på gruns av den inlärda funktionsuppdelningen
fortfarande ha en mycket god överblick.
Samordningen av Stril 60 utbyggnad är ett kapitel för sig, som
jag inte skall trötta läsaren med, men jag vill nämna några orsaker
till att den gick förhållandevis bra. Tekniskt sett var det enkelt att
samordna tack vare funktionsuppdelningen. Alla förändringar
påverkade någon eller några funktionskedjor. Man visste omedelbart
vilka delsystem som var berörda och man kunde snart
uppskatta erforderliga åtgärder. Man kan dock inte beställa utan
pengar. Den ekonomiska planeringen, som inte ens på den tiden
medgav några extravaganser, gjorde att man oftast hade god tid på
sig för teknisk beredning före beställning. På det sättet hade
trögheten i den ekonomiska planeringen positiva följder, men
C FV (Chefen för Flygvapnet) fick vänta på sina önskade funktioner.
Fram till 1967 var flygförvaltningen underställd CFV. Dvs stab
och förvaltning hade samma högsta chef. Det var självklart att
flygstaben sysslade med verksamhetsfrågor och ställde de funktionella
kraven på Stril 60 (och höll i penningpåsen); det var lika självklart
att förvaltningen svarade för de tekniska frågona och anskaffningen.
Ingen ifrågasatte detta. Denna naturliga uppdelning av arbetet har
i varje fall vad gäller flygvapnet i huvudsak bibehållits och fungerat
väl även efter FMV tillkomst.
För att från CFV verkligen nå ut till användarna tillsatte man
senare en särskild grupp för taktisk utprovning av Stril, TUStril.
Detta var enligt min mening ett lika förnuftigt drag som att vid
förvltningen inrätta en enhet för systemfrågor. TUStril hade (och
har fortfarande) sin arbetsplats i en av centralerna och kunde där
kontinuerligt följa och delta i verksamheten och därigenom samla
in erfarenheter från användningen av systemet samt föreslå förändrade
och nya funktioner. Den evolutionära utvecklingen av Stril 60 blev
härigenom både verksamhetsstyrd och användarnära.
En viktig del av systemarbetet är att avgöra vilka nya funktioner
och (stora) förändringar av funktioner som kan tillåtas i systemet.
Detta avgörande baseras på tekniska möjligheter och tillgänglig
ekonomi. Men först bör man pröva de nya ideerna så att man vet,
att de verkligen går att genomföra och framför allt att de ger önskad
utökad funktionalitet. Det är bättre att pröva ideerna innan man
specificerar och beställer, än att efter (den dyra) utvecklingen
konstatera att man att något som är dåligt eller helt enkelt oanvändbart.
Under den evolutionära utvecklingen av strilsystemet gjorde
man sådana idéverifieringar i samverkan mellan CFV (oftast TUStril),
FMV och leverantör, innan man specicerade och beställde det
professionella utvecklingsarbetet. Det fanns två särskilda "centraler"
för detta ändamål, DC Stril främst För utvärdering av metodik
och operatörsfunktioner, PC Stril för värdering och utprovning av
mer genomgripande funktioner. För liknande ändamål inrättades
sådana provningscentraler också på andra ställen inom Försvaret,
t ex PC MASIK inom marinen. 1 denna anda har C3I-laboratorier
inrättats, bl a vid FMV. Avsikten därmed är att man skall pröva nya
idéer innan de beställs som professionell utveckling. Detta är en
väsentlig del av anskaffningsprocessen - en viktig del som många
ofta förbisett.
Om resan börjar idag
Någon kanske tycker att jag skönmålar Stril 60-arbetet; en mänsklig
svaghet är ju att lättare minnas de ljusa upplevelserna än de
alldagliga och mörka! (De verkligt mörka upplevelserna kommer
man nog ihåg, men de var uppenbarligen inte så många.) Visst fanns
det problem och gnissel, men problemen löstes antagligen, eftersom
vi nådde ett gott resultat och gnisslet tonade bort.
Det vore förmätet att tro att framgången inte kan upprepas, även
om vi idag står inför en delvis annan typ av problem. I ledningssystem
på högre nivåer än stril är uppdelningen i delar inte lika uppenbar
som i Stril 60, där teknikområdena så självklart angav delsystemen.
Alla funktioner i taktiska och operativa ledningssystem utnyttjar
högst två delsystem enligt Stril 60-indelning, nämligen kommunikation
samt databehandling och presentation. Men antalet
funktioner ett sådant ledningssystem skall tillhandahålla är mycket
stort. Komplexiteten i Stril 60, som innebar många olika informationskällor,
många olika operatörer, många avnämare, realtidsfunktioner, många olika
kommunikationsvägar etc, har här bytts ut
mot komplexitet i datorprogram och databaser. Denna mycket
koncentrerade komplexitet gör det svårt att få överblick över både
funktioner och data. Den "gamla" uppdelningen i tekniska delsystemområden
kan nu anses motsvara en uppdelning i teknikområden
som datakommunikation, operativsystemteknik, databasteknik,
presentationsteknik etc, och funktionskedjorna skär tvärs
igenom motsvarande delar av systemet. Dagens systemarbete i
denna typ av system blir därför att hålla ordning på dessa funktionskedjor
och hur de påverkar systemets olika delar med målet att
skapa och upprätthålla en god överblick.
Särskilt viktig, men tyvärr inte fullt uppmärksammad, är
överblickbarheten i samverkande system, där de operativa och taktiska
funktionskedjoma går tvärs igenom flera datorsystem, och där
datakällor och databaser är såväl fysiskt som logiskt utspridda. Här
fördras det en ny typ av systemarbete, som understöder en "global"
överblickbarhet och som helt säkert underlättas av en god infrastruktur.
Överblickbarheten är nödvändig, om man skall kunna
göra funktionell betingade ändringar i systemen, eller om man vill
förbättra dem som en följd av den tekniska utvecklingen. Överblickbarheten
är därför ett primärt mål för utveckling av alla
datorbaserade system.
När man anskaffar ett C3I-system, innebär det dels en stor i tiden
näraliggande investering dels kostnader för vidmakthållande, som
belastar systemets budget under många år. De årliga vidmakthållandekostnadema
tenderar att bli större ju äldre systemet blir och
man kan finna en ekonomiskt optimal livslängd, vid vars slut det är
mer lönsamt (eller kanske i dessa sammanhang mindre kostsamt) att
skaffa ett nytt system i stället för att fortsätta använda det gamla. Att
inför anskaffningen beräkna den ekonomiska livslängden är
emellertid svårt, eftersom framtida kostnader för vidmakthållande
är mycket osäkra. Ett sätt att fördela kostnaderna på ett annat vis är
att låta systemet utvecklas evolutionärt eller att tillgripa inkrementell
anskaffning. (Det ena är inte oförenligt med det andra.) Det man
vill åstadkomma är att undvika de höga kostnaderna för underhåll
av gamla system och systemdelar.
Om resan börjar idag kan man lämpligen fördjupa sina ideer
kring följande väsentliga begrepp och gärna konfrontera mina
idéer. En del av dem är konventioneUa, andra kan betraktas som
brandfacklor. Jag hoppas emellertid att de skapar diskussion.
Åsiktsmotsättningar skapar diskussion, och diskussion är en förutsättning för utveckling!
Infrastruktur
En god infrastruktur ger grunden för tillämpningarn och erbjuder
lösningar på de flesta gemensamma problemen. Den är nödvändig
för samverkande informationssystem. Infrastrukturen måste vara
säker för att att tillämpningarna skall bli säkra.
Systemarbete
Detta får inte vara en slentrianmässig beteckning, utan begreppet
måste definieras för varje särskilt fall. Målet med systemarbetet skall
vara överblickbarhet. Påbörja ingen utveckling förrän ideerna prövats
(i ett kvalificerat C3I-laboratorium).
Evolutionär utveckling
Vi får inte tro att vi om tio år blir nöjda med att uppfylla dagens krav!
Utvecklingen fortsätter och möjligheterna ökar. Möjligheter skapar
krav. Planera för det! Det fordras emellertid översyn av våra
upphandlingsregler för att vi tillfullo skall kunna utnyttja utvecklingen
på detta sätt. Evolutionär utveckling är en seriös verksamhet
och ingen lekstuga! All utveckling skall bedrivas professionellt.
Överblickbarhet är en förutsättning för evolutionär utveckling.
Återanvändningr
Att återanvända programvara (och konstruktioner/design) är att
återanvända pengar. Mycket pengar!! Vid utveckling skall vi sträva
efter att åstadkomma återanvändbar programvara och att använda
redan utvecklad programvara!
Samordning
Låt varje organisationsenhet och person bidraga med det den redan
kan! Resultatet av anskaffningen speglar den kompetens vi har, där
kompetens är kunskap, erfarenhet och kontaktnät i lagom portioner.
Samordning kan ske på många sätt, men absolut inte om man
bygger revirstängsel. Vi har inte råd att anskaffa fel. Samordna
verksamhetsstyrda krav med användarkrav och tekniska möjligheter
samt bedriv utvecklingen professionellt och användarnära.
Har resan ett mål?
Resan har ett mål, men på grund av verksamhetsförändringar och
teknisk utveckling förändras målet, och vi hamnar inte där vi först
trodde. Detta är en tjusning och en utmaning. Tjusningen ligger i
att deltaga i evolutionen, utmaningen är att lyckas komma närmare
det nya målet.
Tidigare i denna uppsats beskrev jag den stora förbättring vi
upplevde, när vi fick tillgång till dataöverföring med 9600 bit/sekund.
Idag kan man på optofiber överföra 2500 miljoner bit/sek
och snart ännu mer. Den insatte men försiktige läsaren kanske
frågar: "Kommer man att kräva denna kapacitet?" Grundat på min
tidigare framförda tes "möjligheter skapar krav" vågar jag försäkra:
"Det kommer man att göra!"
Att deltaga i evolutionen innebär att vi behåller det som är bra
och byter ut det som kan bli bättre. Vår resa med obestämt mål blir
paradoxalt nog en utveckling mot vad vi egentligen vill ha!
Christopher Bengtsson
Christopher Bengtsson, anställd vid Försvarets
materielverk, civilingenjör KTH Stockholnl,
var djupt engagerad i Flygvapnets system för
luftbevakning, stridsledning och systenl för
flygledning 1963-1982 med undantag för några
års tjänstgöring i industrin. Han har även
medverkat vid framtagning av taktiska ledningssystem
och är sedan 1982 överingenjör
vid Försvarets materielverks elektronikavdelning, där han för
närvarande arbetar med generella frågor inom informationsteknologiområdet.
|
