På grundlag af bl. a. et af Defence Research Group ledet seminar i Haag den 3.-5. juni 1969 ved SHAPE Tecnical Centre giver major N. C. H. Linde, Hærstaben, i det følgende en oversigt over udviklingen af og status for automatiske kommando- og kontrolsystemer.
Indledning
Gennem de sidste godt 20 år har krigskunsten gennemgået en voldsom udvikling, især karakteriseret ved indførelse af atomkernevåben, øget mobilitet og konventionel ildkraft samt som følge heraf et forudset flydende og spredt kampbillede. Denne udvikling nødvendiggør en tilvejebringelse af nøjagtige, fuldstændige og rettidige informationer for førerens beslutningstagen i en grad, man ikke har set hidtil, samtidig med, at tiden til beslutningstagen er trykket på grund af hurtigheden i våbenlevering og situationsskifte. Herved er fremkommet et behov for en forbedring af de militære kommando- og kontrolsystemer, et behov der synes at kunne tilgodeses ved automatisering under anvendelse af elektronisk databehandling. Sådanne automatiske systemer kan principielt opdeles i
- systemer, der bruges til kontrol af en fysisk, tidstro proces, f. eks. styring af et våbensystem, og
- systemer, der lagrer, behandler og genpræsenterer data til brug for føreren og dennes stab ved disponeringen af enhedens ressourcer, evt. med kapacitet indbygget for deltagelse i selve beslutningstagningen.
I det følgende behandles kun de sidstnævnte systemer, idet der er søgt - i en ikke alt for teknisk form - at give en redegørelse om status for udviklingen af sådanne systemer, systemernes opbygning samt forskellige forhold, der kan være af interesse for en bruger. I USA begyndte man allerede først i 1950’erne udviklingen af automatiske kommando- og kontrolsystemer, en udvikling, der ikke alene er karakteriseret ved teknologiske fremskridt i materiel (hardware) og programmel*) (software), men også ved en løbende ændring i de metoder, der blev anvendt ved systemopbygningen. Især i begyndelsen var indsatsen spredt, ukoordineret og oftest kendetegnet ved, at man automatiserede uden forudgående analyse af, hvad man ville opnå. Mange systemer kom derfor adrig til at opfylde forventningerne, og der fremkom systemer uden det samordnede rapporteringssystem, der skulle tilvejebringe de nødvendige data. Man så også, at identiske data blev lagret i forskellig form i forskellige systemer, og at det i almindelighed ikke var muligt at flytte programmer og data fra ét system til et andet. Dette forhold - der kan belyses af, at der i dag findes mere end 2000 forskellige militære systemer, anvendende 215 datamat-modeller fra 33 firmaer og mere end 100 programmeringssprog og -dialekter - har medført, at man i de senere år har lagt vægt på en udvikling, der nok er langsommere og mere bekostelig, men bygger på en grundlæggende systemanalyse og hensynet til koordination.
*) D.v.s. alt det, der foruden datamaten og andet egentligt materiel er nødvendigt for anlæggets udnyttelse - f.eks. programmeringssprog
Ingen af disse systemer er - og vil næppe blive - cost-effective i den betydning, at de vil medføre økonomiske besparelser. Der findes intet større kommando- og kontrolsystem, der er resulteret i besparelser, der overskrider udgiften til udvikling, udnyttelse og vedligeholdelse af systemet. Ønskes sådanne systemer, må de motiveres ved, at de forsyner os med en evne til at klare opgaver, der ikke kunne løses uden automatik, eller at der tilvejebringes en øget effektivitet, der modsvarer udgiften. I det foranstående er udviklingen i USA nævnt som et eksempel. Behovet fremstod først der, idet man blev tvunget til at effektivisere kommandosystemer m.v., så de kunne følge med den tekniske udvikling på andre områder og tilgodese hensynet til USA’s voksende verdensomspændende forpligtelser. USA begyndte derfor og er i dag længst fremme, men såvel indenfor NATO som i en række andre lande er automatiske systemer indført eller under udvikling. I denne artikel er ikke givet beskrivelser af noget konkret system, idet emnet er begrænset til alene at behandle visse principielle forhold og problemer i forbindelse med udvikling af automatiske kommando- og kontrolsystemer.
Systemudvikling Det karakteristiske for EDB-baserede systemer er, at behov og specifikationer må tilvejebringes i mere detaljeret form end nødvendigt for et manuelt system, idet systemets opførsel er bestemt af EDB-programmet. Et sådant system mangler den dynamiske smidighed, som et manuelt system indeholder, og er derfor ude af stand til at behandle situationer, der ikke var taget i regning ved systemopbygning og programmering. Dette betyder ikke alene, at alt skal beskrives for enhver valgmulighed og beslutning, men også at alle situationer, som systemet kan blive stillet over for, må kortlægges på forhånd. Dette gør systemopbygningen bekostelig - man regner i dag med, at udgiften til analyse og systemopbygning m.v. andrager ca. % af den totale udgift, materieludgiften kun ca. 1/4.
Systemudvikling kan principielt ske med anvendelse af 3 metoder :
1. Man begynder med at anskaffe en datamat og undersøger dernæst, hvilke stabsfunktioner den pågældende maskine kan hjælpe. Herved opnås nok hurtighed i etablering af systemet, men metoden bør forkastes, idet man investerer i en datamat, hvis opgave ikke er klarlagt. Datamatens konfiguration (opbygning) bør bestemmes af den analyserede opgave.
2. Man automatiserer de hidtidige manuelle funktioner. Herved opnås hurtig afgørelse af automatiseringens omfang, og man letter valg af datamat og udvikling af program m.v., men også denne metode bør forkastes, da den bygger på to ikke beviselige forudsætninger:
- at den manuelle procedure er korrekt, og
- at den manuelle procedure er rationel,
og man således i givet fald kan indføre alvorlige systemfejl.
3. Man gennemfører en fuldstændig analyse af den pågældende myndigheds struktur, begyndende med en kortlægning af den pågældende førers opgave, hans ressourcer og truslen*). Det næste skridt i omformningen af den gældende procedure til et informationssystem er en opdeling (afgrænsning) af de enkelte stabsfunktioner, prioritering heraf og fastlæggelse af, hvilke data, der er nødvendige for den enkelte funktion. Herefter kan man kortlægge de kilder, hvorfra de nødvendige data skal komme, fastlægge hvilken behandling, disse data skal underkastes, og metode for denne behandling, og endelig, hvorledes udlæste data skal præsenteres. En sådan systemopbygning, der sigter mod udvikling af et datamat-orienteret system, bør videre følge 8 love:
- Den ønskede anvendelse af systemet skal nøje specificeres.
- Det bør først og fremmest undersøges, om man ved forbedring af det hidtidige manuelle system kan opnå den nødvendige effekt.
- Hvis det påvises, at visse stabsfunktioner bør automatiseres, behøver dette ikke at medføre en automatisering af samtlige funktioner, idet man meget vel kan acceptere manuelle delsystemer i det samlede system.
- Enhver mulighed for afprøvning af systemet bør udnyttes under opbygningen.
- Systemudviklingen bør gennemføres på det sted, det skal virke.
- Systemet skal udvikles trin for trin og holdes så simpelt som muligt.
- Systemændringer bør begrænses mest muligt.
- Den potentielle bruger skal deltage i udviklingsarbejdet.
*) Ved en sådan analyse må »truslen« omfatte såvel truslen efter almindelig definition (en forudset, men endnu ikke opstået skade = den positive trussel) som »den negative trussel« (defineret som en forudset, men endnu ikke opstået fordel = egen kapacitet), d.v.s. at man betragter et samlet trusselsbillede i form af et integreret kampsystem.
Den sidst anførte lov kan give anledning til overvejelse, om systemopbygning m.v. bør gennemføres af stabens egne officerer med fornøden konsultativ hjælp, eller om den bør pålægges et hold »udefra« med bistand fra stabens officerer. For kommando- og kontrolsystemer må den første mulighed normalt være den mest hensigtsmæssige, idet man opnår,
- at systembyggerae er indlevet i myndighedens opgave m.v. på forhånd,
- at det samme »hold« gennemfører hele arbejdet (opgavebeskrivelse m.v. må under alle omstændigheder udføres af stabens officerer),
- at bruger-deltagelse på alle trin sikres,
- at sikkerhedshensyn lettere tilgodeses,
- at viden om systemet, dets opbygning og funktionering »forbliver i huset«, og - at man anvender det samme personel, som senere skal drive systemet.
Ved automatisering af flere niveauer i et kommando-system kunne det umiddelbart forekomme naturligt at begynde »fra oven«. Herved opnås, at krav til underlagte enheder formuleres efter behov, ligesom koordination - også for materiel og programmel - lettes. De hidtidige erfaringer synes imidlertid at vise, at det er mest hensigtsmæssigt at begynde fra bunden, hvilket bl.a. kan motiveres ved,
- At det automatiserede system indføres i et allerede virkende system, der ved sin udvikling ikke har taget automatisering i regning. Ved en opbygning fra oven kan man opsummere behov efter recepten »nice to have« (Parkinsons lov) i en sådan størrelsesorden, at det på de lavere trin ikke er muligt at tilgodese dem.
- At man begrænser den byrde, der lægges på de lavere trin under systemopbygningen.
- At en opbygning fra oven giver et større behov for personeltilgang end en opbygning fra neden, jf. første »pind«.
En opbygning fra neden må selvfølgelig ikke betyde, at behov fra oven tilsidesættes eller overses, samt at man undlader at koordinere, men kun at tilføjende behov må følges op ved tilførsel af ressourcer på de lavere trin, idet koordination m.v. gennemføres som et led i systemanalysen.
Betragtninger vedrørende automatiske kommando- og kontrolsystemer Automatiske systemer kontra kommandostruktur
Det i dag forudsete kampbillede vil i den fortsatte udvikling kunne motivere organisatoriske ændringer, hvor mindre enheder gives evne til føring af en selvstændig kamp og med skiftende kommandoforhold. I den givne situation kan det herunder være hensigtsmæssigt at tildele en kommandomyndighed et større antal dispositionsenheder, end det hidtil har været anset for hensigtsmæssigt. Denne udvikling kan forstærke behovet for indførelse af et automatisk system, idet et sådant system netop - hvis de fornødne hensyn er taget i systemopbygningen - vil muliggøre hurtig skift i kommandoforhold og lette føring af et større antal dispositionenheder i en løsere organisationsstruktur, f. eks. hvis en divisionschef i en given situation ønsker at føre en eller flere bataljonskampgrupper direkte.
Overlevelsesevne
Et systems overlevelsesevne afhænger af, i hvilket omfang det vil kunne fortsætte sin funktion, hvis dele af det (EDB-materiel, telekommunikationer, en hel stab m.v.) falder ud, samt af sandsynligheden for, at der kan ske »udfald«. Overlevelsesevnen er således betinget dels af eget systems struktur, dels af fjendens muligheder for at indvirke på systemet (det tilsvarende fjendtlige system), d.v.s. af træk i det totale kamp-system. På dette grundlag bør overlevelsesevnen gøres til genstand for en særlig analyse, og vil som oftest betinge, at der må tilføres supplerende tekniske midler m.v., så der kan gennemføres en umiddelbar strukturel ændring, hvis en stab og dens systembidrag falder ud. Medens de normale rapporterings- og kommandokanaler funktionerer med henblik på at formidle de aktuelle data for systemet, tilføjes således et samordnet delsystem, der har til opgave i den givne situation at ændre parametre og data, når ændring i kommandostruktur indtræffer. Dette delsystem er da i stand til at give f.eks. en divisionschef de nødvendige data for - hvis brigaden falder ud - at tage direkte kommando over brigadens enheder. Det ses, at et sådant delsystem, foruden at styre ændringer som følge af udfald i systemet, kan samordnes med de hensyn, der tages i systemet for at tilgodese de foran nævnte skift i kommandoforhold. Det bemærkes, at indbygger man ikke en sådan overlevelsesevne i systemet, vil det være nødvendigt på anden vis at skaffe en reserve, f. eks. i form af et bibeholdt manuelt system, men herved fremkommer øgede krav til uddannelse m.v., idet der etableres to forskellige procedurer.
Datamængden
Den meget store kapacitet for lagring m.v. af data, som tilføres i et automatisk system, indebærer en fare for, at stabene overlæsses med data og dermed, at man igen ikke kan overse alle relevante data. Det er derfor nødvendigt, at der i systemet sker en kraftig filtrering af data, så kun nødvendige data tilgår de enkelte stabe og stabselementer.
Menneske kontra datamat
Som tidligere nævnt kan en datamat ikke mestre situationer, der ikke er indeholdt i programmet med hver valgmulighed og kriterierne herfor nøje beskrevet. På grund af datamatens store kapacitet er det imidlertid muligt at indkode meget omfattende direktiver for løsning (beslutning) i en valgsituation, blot alle kriterier og deres indbyrdes vægt kan kortlægges nøjagtigt. Derfor kan en datamat opføre sig, som om den alligevel kunne »tænke«, f. eks. spille skak, dam o.s.v. Man har således et eksempel på, at man har »lært« en datamat at deltage i den tændstikleg, hvor 2 parter skal tage tændstikker på skift fra et antal bunker, og hvor det gælder om at undgå at få den sidste tændstik. Datamaten vinder altid, og prøver man at snyde, udskriver den: »Snyder du, så snyder jeg også«, og man kommer igen til kort.
Man kan således programmere en datamat til at træffe - eller anbefale - beslutninger.
I et system, hvor man inddrager visse beslutningsområder i automatiseringen, må man foretage en klar afgrænsning af, hvilke beslutninger, der fortsat skal tages af føreren og hans hjælpere, og hvilke, der kan overlades til EDB. I en sådan vurdering kan man nå frem til, at en bestemt afgørelse bør træffes af en officer, men konstaterer man herefter ved en nøjere undersøgelse, at officerens afgørelse - på grund af tidshensyn og problemets kompleksitet - normalt træffes efter en tommelfingerregel, da vil afgørelsen mere hensigtsmæssigt kunne overføres til EDB-programmet.
Et andet forhold bør nævnes i forbindelse med relationen menneskemaskine: den rådige ind- og udlæsningsteknik, der i dag må anses at være en hindring for stabsofficerens egen udnyttelse af EDB. Denne kommunikation kan i dag ikke ske i »klart sprog« og kort, men må gives en omstændelig form. Ønsker et medlem af en divisionsstab f. eks. svar på et så enkelt spørgsmål som: »Hvor mange, operationsklare middeltunge kampvogne har X brigade?« må spørgsmålet i princippet udformes således:
1. Hent materiel-statusregisteret.
2. Hvis enheden er X brigade, og.
3. Hvis materielgenstanden ér middeltung kampvogn.
4. Tæl.
5. Udskriv summen.
Det er denne kommunikationsskranke, der er den principielle hindring for at gøre datamaten nyttig for enhver fører — et forhold, der først kan ventes tilfredsstillende tilgodeset godt hen i 1970’erne, hvor man forudser en udvikling, der muliggør korrespondance med en datamat med anvendelse af »daglig tale«.
Begrænsninger
På sit nuværende udviklingsstade (3. generations materiel og programmel) betinger teknikken i dag, at man til en vis grad må give afkald på simpelhed og hurtighed, idet det ikke er muligt at lagre alle relevante data på en hurtig tilgængelig måde. Dette hænger sammen med, at selve datamaten kun kan rumme et begrænset antal data, således at de store datamængder må opbevares i tilsluttede lagerenheder (baggrundslagre). Hver af disse baggrundslagre (f. eks. et antal magnetbåndstationer) rummer et »register«, og ønsker man oplysninger fra baggrundslagrene, må man vide, i hvilket register, der skal søges og opgive dette i ordren til datamaten. I den udstrækning, vi kan forudsige mulige spørgsmål, kan vi ordne de berørte data for en hurtig udskrivning, men for uforudsigelige spørgsmål er det ofte nødvendigt at foretage en langvarig eftersøgning i lageret efter det register i lageret, hvor de pågældende data er anbragt, og hvis de enkelte data, der ønskes, er lagret i forskellige registre, må der stilles flere spørgsmål, i antal efter antallet af berørte registre. Proceduren kompliceres således på to måder:
- spørgeformen er ikke naturlig, jf. det foregående punkt,
- brugeren må på forhånd vide, i hvilket register, han skal søge efter ønskede data.
Et system med disse begrænsninger er kun nyttigt for personel, der er uddannet i EDB og data-systemer samt specielt trænet i det pågældende system. Eller sagt på en mere direkte måde, sådanne systemer vil kun i begrænset omfang være direkte og personligt anvendelige for en senior officer.
Anvendelse af centrale datalagre
EDB er nøglen til at kunne gøre effektiv brug af den uhyre datamængde, der kan præsenteres for en fører. Hurtighed og simpelhed med hensyn til udtagning (udlæsning) af data står i omvendt forhold til størrelsen og spredningen i lagrene. Det er derfor i dag urealistisk at prøve på at udvikle store, centrale data-lagre. I endnu en årrække vil det være nødvendigt at begrænse graden af integrering. En rent praktisk begrænsning herfor er beskrevet i det følgende punkt.
Samordning af systemer
Som nævnt i indledningen har begyndelsesvanskelighedeme vedrørende udvikling af data-systemer medført en jungle af systemer, datamater og programmel, og de sidste par års bestræbelser har bl.a. været koncentreret om forsøg på at tilvejebringe en fornøden kommunikation systemerne imellem. Behovet kan opstilles således, at man ønsker mellem berørte systemer at kunne flytte programmer og data ved datatransmission. En sådan flyttelighed kan have 3 grader:
1. Identitet.
2. Oversættelighed.
3. Omsættelighed.
Den dynamiske funktion i én militær stab gør såvel oversættelighed som omsættelighed uønsket, idet disse muligheder, der ikke skal beskrives nærmere her, ofte er for tidskrævende. Dette betyder ikke, at vi behøver identiske datamater for at opnå flyttelighed for programmel, det betyder kun, at det anvendte programmel ikke kan gøres datamatafhængig. For at et program kan anses at være flyttelig fra én datamat til en anden, er det ikke tilstrækkeligt, at man rent fysisk kan gennemføre flytningen, det må også kunne ske på en tilstrækkelig effektiv måde. Dette indebærer meget mere end at skrive programmer i samme sprog. Det nødvendiggør, at datamater, mellem hvilke en sådan flytning ønskes, skal have visse fælles karakteristika: opbygning, ordlængde, lagerstruktur, indlæsning/udlæsning struktur, tilsluttede faciliteter m.v. En sådan ensartethed kan tilvejebringes ved standardisering, enten ved aftale fabrikanterne imellem, eller på brugerinitiativ, men det vil formentlig tage mange år, før en sådan standard er til rådighed. Indtil da vil muligheden for flytning af programmer (til forskel fra data) alene ved programmel være yderst begrænset, men en mulig løsning vil være standardisering af systemer. Herved kan opnås data-flyttelighed mellem alle datamater, der benytter det pågældende system, ligesom kommunikationen bruger-datamat standardiseres. Denne løsning indebærer samtidig mulighed for besparelser rent økonomisk, men man må naturligvis være opmærksom på, at man ikke i denne standardiserings navn indfører systemer, der ikke tilgodeser den ønskede anvendelse.
Niveau
Det vil altid være et spørgsmål, hvor langt ned man skal føre en automatisering. Afgørelse herom må være et led i systemanalysen, men afhænger bl.a. af, hvilken overlevelsesevne, der indbygges, og de tildelte opgaver på pågældende niveau. Indbygges en høj grad af overlevelsesevne, kan systemet føres ret så langt ned, men det er f. eks. næppe hensigtsmæssigt at pålægge en delingsfører i et panserinfanterikompagni ved siden af sin egentlige opgave at skulle betjene et panel for indlæsning af data i et system (data, der normalt skal omsættes til cifre, da dette er det mest hensigsmæssige af hensyn til databehandling og -transmission). På de laveste trin må der fortsat blive tale om et manuelt system, der fra et vist niveau formidler indlæsningen af de grundlæggende data i det automatiserede system. Den tekniske udvikling - først og fremmest udvikling af en simplere og mere naturlig kommunikation menneske-datamat, vil kunne sænke dette niveau.
N. C. H. Linde
Kilder
Artiklen er blandt andet skrevet på grundlag af emnets behandling på et seminar 3-5 juni 1969 i Haag ved SHAPE Technical Centre, ledet af Defence Research Group. Der kan herved specielt henvises til følgende indlæg, der foreligger i trykt form: Eric W. Wolfy Technical Director Naval Command Systems Support Activity: Command Information Systems, what was promissed, what we have and what we need.
J. Lustzow and E. Anschuetz, Technical C&C Office, Bonn: Considerations to the establishment of military requirements for Command Systems. John P. Gartland, Commander US Navy: Determination of military requirements for the use of computers in the SACLANT Command, Control and Information System. Ray W. Fuller, Colonel, Management Information Systems Directorate, Office of the Chief of Staff, US Army: Development of automatic data systems for the army in the field. J. Gosden, S. Bramssen, J. Fry, S. Mahle, H. Sternick, MITRE Corporation, USA: Acheiving inter-ADP Centre compatibility*
