Tillbaka till Omgivningssimulator
Sida 7

1 Designstrategi

För att försöka uppfylla kraven under Definition ovan har jag valt följande lösningar.

1.0.1 Generalitet

Kan approximeras med kombinationen utbyggbarhet och användarvänlighet. Svårigheten här ligger i att hitta en modell för utbyggnad som också är lättanvänd och begriplig. Införandet av nya EXS kan innebära att nya data måste kunna uppdateras i omvärlden och föras över till EXSen. Dessutom tillkommer hela tiden ytterligare krav på funktionalitet i samband med att med att man vill testa nya funktioner i C3-systemet. Hur kunna enkelt introducera denna data i omvärlden?
En ide' är att använda en objektorienterad design av den simulerade omvärlden med en bas av klasser som är såpass generella att de alltid kan användas för att härleda en ny klass av objekt, som innehåller den nya informationen.
Sedan skapar man en ny Meddelandetyp (Se kapitlet Meddelandetyper) med tillhörande extraktorfunktioner som kan överföra denna information till EXS. Detta medför att SIM- och NET-modulerna i ENS och EXS (de som berörs av ändringen) måste kompileras om.
Redan existerande Meddelandetyper får INTE modifieras, p.g.a att bakåtkompatibilitet är önskvärt om EXS:er som använder den gamla versionen ska återanvändas.
Skapande av nya Meddelandetyper kan leda till hög nätbelastning om man har en konfiguration av nya och gamla EXS:er, som begär olika varianter av i stort sett samma information.

1.0.2 Spelfiler

Ett scenario är tänkt att byggas med hjälp av ett grafiskt gränssnitt och sedan lagras på en fil. Scenariot kan sedan laddas in och köras ett godtyckligt antal gånger. Under definitionsfasen av ett scenario kan alltid ändringar göras och scenariot kan sparas.

1.0.3 Snabbspolning

Ett scenario kan "snabbspolas" från spelstart till önskad starttid genom att spelets tid uppdateras med en given faktor gånger reell tid. Detta innebär att snabbspolningshastigheten begränsas av scenariots uppdateringsintervall. Under snabbspolning utförs varken uppdatering av det grafiska gränssnittet eller sändning av data till EXS.

1.0.4 Feedback

C3-systemets påverkan på omvärlden via extern utrustning simuleras med hjälp av RPC/XDR-procedurer som arbetar direkt på den simulerade omvärlden. Felrapportering från EXS sker också med RPC/XDR.

1.0.5 Flera användare

För att möjliggöra testning av kommunikationsutrustning och rapporteringsfunktioner behövs ibland att två eller flera C3-system kan dela samma omgivning. Detta kräver att

1. Flera egna system måste kunna finnas i omvärlden.
2. Olika omgivningsdata måste kunna ges till olika C3-system
3. EXS måste veta till vilket eget-system-objekt de tillhör
4. Vilket objekt som helst måste kunna väljas som eget system
5. Objekt valda som eget system till något anslutet C3-system får ej kunna raderas
6. Måste hålla reda på till vilket objekt/eget-system som vissa omgivningsdata hör

1.0.6 Orderkanal

Det tillkommer alltid nya krav på ytterligare funktioner för styrning av simulerad utrustning, d.v.s EXS. T.ex vid testning av C3-systemets reaktion på felaktig indata, utrustningsfel, m.m. För att dessa "order" ska kunna läggas in vid en viss tidpunkt eller i en viss sekvens måste de ha en koppling till scenariohanteringen. En lösning är att ha en lista av tidsbestämda "globala" händelser samt en lista över anslutna EXS och deras adresser, för unicast av order till en viss EXS. Nya order kan alltid definieras enligt metoden beskriven under Generalitet ovan.

Sida 9