Interoperabiliteitsexports en -imports

Een run schrijft een resultaatdocument, een grafiek en een rapport. --export schrijft ook de geometrie van het scenario, of zijn gesynthetiseerde signaal, in de formaten die andere hulpmiddelen al lezen: een globeviewer, een desktopkaart, een geografisch informatiesysteem (GIS), een missieanalysepakket of een software-defined-radio-hulpmiddel (SDR). Niets hiervan leest een klok of het netwerk, en geen enkele export draagt een tijdstempel van aanmaak, dus hetzelfde scenario geeft bij elke run byte-identieke bestanden.

kshana scenarios/jamming-demo.toml --export czml            # one format
kshana scenarios/jamming-demo.toml --export kml --export geojson
kshana scenarios/jamming-demo.toml --export all             # every format that applies
kshana scenarios/jamming-demo.toml --export list            # which apply, and why not, without running
kshana scenarios/terrain-nav.toml --import-route route.geojson --export geojson

Bestanden worden naast het scenario geschreven, genoemd zoals het resultaatdocument: jamming-demo.czml, jamming-demo.kml, jamming-demo.geojson, één jamming-demo.<object>.e per bewegend object (of jamming-demo.e wanneer er één is), en het paar l-band-waterfall-jamming.sigmf-meta / .sigmf-data. Met --study-name nemen ze in plaats daarvan de naam van de studie over, zoals de andere uitvoer.

Een expliciet genoemd formaat dat niet op het scenario van toepassing is, is een fout die de reden afdrukt; onder all wordt de reden afgedrukt en het formaat overgeslagen. De ingangen van de bibliotheek zijn kshana::interop::export(src, format), kshana::interop::plan(src) en kshana::interop::geojson::apply_route(src, geojson); ze nemen de scenariotekst en geven bytes terug, zonder een bestand aan te raken, dus ze draaien ook in de WebAssembly-build. De Model Context Protocol-server (MCP) biedt dezelfde drie aan als de hulpmiddelen export_interop, list_export_formats en import_route (zie mcp/kshana-mcp/README.md).

Code: src/interop/ (scene.rs bouwt één geometrische beschrijving van het scenario, czml.rs, kml.rs, geojson.rs en stk.rs schrijven die), src/sigmf.rs en src/spectrum.rs voor het signaal. Tests: tests/interop_formats.rs.

Formaten#

Wat elk bestand bevat#

Elk geospatiaal formaat wordt uit dezelfde scène geschreven, dus ze kunnen het niet oneens zijn over waar iets zich bevindt. Een scène heeft tot vier soorten objecten:

• Bewegende objecten — satellieten, en een gebruikersplatform wanneer dat beweegt — bemonsterd op het eigen tijdraster van het scenario met de propagatoren die de run van het type gebruikt.
• Vaste locaties — een ontvanger, een grondstation, een jammer, of de oorsprong van een lokaal navigatiestelsel.
• Sporen zonder tijd — de waypoints die een type voor alternatieve positiebepaling, navigatie en tijdsynchronisatie (PNT) met terrein, zwaartekracht of een combinatie vliegt. Deze typen hebben geen tijdas, dus de sporen dragen er geen.
• Voetafdrukken van jammers — voor het type jamming twee cirkels rond de jammer: de afstand over de grond waarbinnen een satelliet in het zenit (de sterkste) onder de volgdrempel valt, zodat elke satelliet verloren gaat, en de afstand waarbinnen een satelliet op het elevatiemasker (de zwakste) dat doet, zodat het volgen begint uit te vallen. Beide komen uit de eigen linkvergelijkingen van het type (Kaplan en Hegarty, Understanding GPS/GNSS (Global Positioning System / Global Navigation Satellite Systems), 3e druk, §9,4) met de jammer aan de horizon van de ontvanger en vrijeruimteverlies, en de testsuite controleert dat de effectieve verhouding tussen draaggolf en ruisdichtheid op elke straal gelijk is aan de drempel tot 1e-6 dB. De cirkel wordt getekend op een bol met de gemiddelde straal van de aarde.

CZML#

Het eerste pakket is het documentpakket ("id": "document", "version": "1.0") met een klok die het tijdraster overspant. Elk bewegend object is een pakket waarvan position een ISO 8601 (datum- en tijdnotatie van de International Organization for Standardization) UTC (Coordinated Universal Time) epoch heeft, referenceFrame "INERTIAL", en cartesian-samples [t, x, y, z, ...]: seconden na het epoch, meters in het Geocentric Celestial Reference System (GCRS). CesiumJS neemt INERTIAL als het International Celestial Reference Frame (ICRF), waarvan de assen het GCRS deelt. Vaste locaties en middelpunten van voetafdrukken zijn constante aardvaste posities cartesian met referenceFrame "FIXED". Een voetafdruk is een ellipse met beide halve assen gelijk aan zijn straal; een spoor zonder tijd een aan de grond vastgeklemde polyline. De description van elk pakket noemt het stelsel nogmaals in woorden.

KML#

Eén <Document> met een <Folder> per objectklasse. Een bewegend object is een <Placemark> met een <gx:Track>: één <when> per sample (ISO 8601 UTC), daarna één <gx:coord> per sample (lengtegraad, breedtegraad, hoogte). Locaties zijn <Point>s, voetafdrukken <Polygon>s waarvan de ring gesloten is en tegen de klok in loopt, sporen zonder tijd <LineString>s. Coördinaten zijn lengte- en breedtegraad in het World Geodetic System 1984 (WGS 84) in decimale graden en hoogte in meters boven de WGS 84-ellipsoïde, geschreven met altitudeMode absolute. KML leest absolute als hoogte boven gemiddeld zeeniveau; het verschil, de geoïde-ondulatie, ligt binnen ongeveer ±110 m en wordt niet toegepast. De beschrijving van het document zegt dat.

GeoJSON#

Eén FeatureCollection. Posities zijn [longitude, latitude] of [longitude, latitude, height] — lengtegraad eerst, zoals RFC 7946 vereist — in WGS 84-graden, met hoogte in meters boven de ellipsoïde. Een bewegend object is een LineString met een eigenschap times_utc die één ISO 8601-tijd per positie bevat; een spoor dat de meridiaan van 180° kruist, wordt geschreven als een MultiLineString die daar is afgesneden, zoals RFC 7946 §3.1.9 vraagt (het kruispunt wordt geïnterpoleerd, en times_utc vermeldt dan alleen de oorspronkelijke samples). Locaties zijn Points, voetafdrukken Polygons met een gesloten buitenring tegen de klok in (§3.1.6), sporen zonder tijd LineStrings. Elke feature heeft een eigenschap units die de eenheid van elk numeriek lid noemt.

STK .e#

Eén bestand per bewegend object, omdat een STK-efemeride één voertuig beschrijft. De header geeft NumberOfEphemerisPoints (gelijk aan het aantal gegevensrijen), ScenarioEpoch (UTC, d Mon yyyy hh:mm:ss.ssssss), InterpolationMethod Lagrange met InterpolationSamplesM1 5, CentralBody Earth, CoordinateSystem ICRF en DistanceUnit Meters; de rijen onder EphemerisTimePosVel zijn seconden na het epoch, positie in meters en snelheid in meters per seconde, in het GCRS. Een scène met alleen vaste locaties of sporen zonder tijd schrijft geen bestand .e: een vast punt is een STK Facility, geen efemeride. Een id die geen gewoon deel van een bestandsnaam is (een constellatieschil en een satelliet, Pulsar inclined/S1-0163) wordt geschreven met elk ander teken als -, genummerd als twee id's dan samenvallen.

Het type leo-pass en het type leo-pnt-chain (via zijn fase [pass]) exporteren elke satelliet in een lage baan om de aarde (LEO) en de gebruiker uit de eigen propagatoren en het tijdraster van het type. Het type werkt in ECI0, het aardgecentreerde inertiële stelsel dat op het epoch met het aardvaste stelsel samenvalt; elk sample wordt op zijn eigen tijd door de aardrotatie van het type omgezet in het aardvaste stelsel en vandaar in het GCRS via het stelsel met ware evenaar en gemiddelde equinox (TEME) waarin de propagator Simplified General Perturbations 4 (SGP4) uitvoer geeft, op dat moment, met UT1 (Universal Time, de hoek van de aardrotatie) gelijkgesteld aan UTC en poolbeweging verwaarloosd, zoals bij de andere exports. De andere LEO-typen geven aan waarom een formaat niet van toepassing is (de tabel hieronder).

Campagnes#

Een campaign exporteert elk lidscenario met geometrie als een eigen bestandsset, met het label van het lid ingevoegd vóór het formaatachtervoegsel: elke fase-run (<phase>, of <phase>-<k> wanneer de fase meerdere runs heeft), het basisscenario van de sweep (sweep), het Monte Carlo-scenario (monte-carlo) en elk samengesteld lid (zijn label, met de gedeelde waarden die het bindt erin geschreven). campaign-shared-jammer-sea-road.toml --export kml schrijft campaign-shared-jammer-sea-road.ship-strait.kml en campaign-shared-jammer-sea-road.car-coast-road.kml. Een lid dat identiek is aan een eerder lid wordt eenmaal geschreven, en waarden die een campagne tijdens de run toepast (overdrachten, sweepwaarden, seeds) staan niet in het geëxporteerde lid. Een formaat is van toepassing op een campagne wanneer het op enig lid van toepassing is; anders is de reden noot 4 van de tabel hieronder. Zie CAMPAIGNS.md.

SigMF#

De snapshot [iq] van het type spectrum — de gemodelleerde L-band getekend als complexe samples op één moment — als paar .sigmf-meta / .sigmf-data, in het gegevenstype dat [iq] noemt (cf32_le of ci16_le). Het is dezelfde opname die de run schrijft en terugleest voor zijn eigen consistentiecontrole: de geëxporteerde metadata zijn gelijk aan het blok iq.sigmf.meta van het resultaatdocument, en het gegevensbestand heeft de lengte iq.sigmf.data_bytes. De schrijver is src/sigmf.rs, de module die het type spectrum al gebruikte; er wordt niets gedupliceerd.

Stelsels en tijd#

• De engine propageert in TEME (ware evenaar, gemiddelde equinox van de datum), zijn eigen stelsel. Bewegende objecten worden naar het GCRS gedraaid door de reductie nutation::teme_to_gcrs (IAU 2006-precessie en IAU 2000B-nutatie, waarbij IAU de International Astronomical Union is), die het gepubliceerde voorbeeld van Vallado voor TEME naar GCRF (Geocentric Celestial Reference Frame) tot 0,11 m reproduceert, voor CZML en STK, en naar het aardvaste stelsel door frames::teme_to_ecef voor KML en GeoJSON. De aardvaste rotatie is de gemiddelde sterrenhoek van Greenwich met UT1 gelijkgesteld aan UTC en zonder poolbeweging — dezelfde reductie die de SP3-export (Standard Product 3) gebruikt. Op de baanstraal van GPS verschuift de verwaarloosde UT1−UTC van maximaal 0,9 s de lengtegraad van een satelliet met maximaal ongeveer 1,7 km; grondlocaties worden er niet door beïnvloed, omdat ze in breedte- en lengtegraad worden opgegeven.
• Het type ephemeris is de uitzondering: zijn engine-uitvoer bevat al posities in het GCRS en aardvast (met de UT1−UTC en poolbeweging van het scenario, of een echte reeks van de International Earth Rotation and Reference Systems Service (IERS)), en die worden ongewijzigd geschreven.
• Elke tijd is UTC. Schrikkelseconden worden niet gemodelleerd: een verschil over een schrikkelseconde heen wordt geteld alsof elke dag 86.400 s had, zoals de tijdrasters van de engine tellen.
• Het epoch van t = 0 is dat wat de run van het type gebruikt, en elk bestand noemt het: de epoch van het type orbit; wanneer die ontbreekt, het vroegste epoch dat de eigen gegevens van de satellieten dragen (een epoch van een two-line element set (TLE), de referentietijd van een uitgezonden efemeride, het begin van een SP3-bestand), en 2000-01-01T00:00:00Z alleen wanneer geen enkele satelliet er een draagt (Kepler-elementen). De exports voor SP3 en OEM (Orbit Ephemeris Message) houden 2000-01-01T00:00:00Z aan voor een scenario zonder epoch, dus voor zo'n scenario wijken hun datums af van die van deze bestanden. Zonder epoch van het scenario wordt elke satelliet die een eigen epoch draagt, op zijn eigen moment (zijn epoch plus t) in het GCRS en de aardvaste stelsels gedraaid, omdat dat de datum is waartoe zijn TEME-positie behoort; waar de epochs van de satellieten verschillen, volgen de gedeelde tijdlabels de aanname van de engine dat elke satelliet begint op t = 0, en het bestand zegt met hoeveel uur ze verschillen. Het SGP4-elementepoch van de Walker-constellaties van de typen jamming en gnss-sim (2018-06-12T00:00:00Z), dat hun runs ook voor de aardrotatie gebruiken; het epoch van het type passes; het epoch of TLE-epoch van het type ephemeris. Het type integrity heeft geen kalenderepoch; zijn export dateert t = 0 zoals bij een baanscenario zonder.
• Satellieten houden de positionele identificatoren G01, G02, ... die de exports voor SP3 en OEM hun geven, omdat de propagatoren de naamregels van de TLE niet meedragen.

Imports#

• GeoJSON-route. --import-route <file> (bibliotheek: interop::geojson::apply_route) leest de eerste LineString van een GeoJSON-document — een kale geometrie, een Feature of een FeatureCollection — en schrijft die vóór de run in de spoorinvoer van terrain-nav, terrain-slam, gravity-map en combined-altpnt (start_lat_deg, start_lon_deg, step_lat_deg, step_lon_deg, waypoints). Die typen vliegen start + i·step, dus een route wordt geaccepteerd wanneer ze precies dat is: haar twee uiteinden (het aantal waypoints van het scenario blijft behouden), of drie of meer posities gelijkmatig verdeeld op een rechte lijn in breedte- en lengtegraad, tot op 1e-7 graad (ongeveer 1 cm). Elke andere route wordt geweigerd en de fout noemt de positie die het verst van de lijn ligt. Een route voor een type zonder trajectinvoer wordt met die reden geweigerd. Lengte- en breedtegraad worden op bereik gecontroleerd, wat een bestand met de breedtegraad eerst vangt.
• SigMF-opname. Het blok [recording] van het type spectrum leest een paar .sigmf-meta / .sigmf-data via src/sigmf.rs en tekent zijn Welch-schatting naast het model (zie SPECTRUM.md). Bestanden lezen is een functie van de native build; de WebAssembly-build neemt de bytes aan via kshana::sigmf::read.

Hoe de exports worden gecontroleerd#

tests/interop_formats.rs parst elke export met een validator die uit de specificatie van het formaat is geschreven, niet met de eigen code van de schrijver:

• CZML: een JSON-array waarvan het eerste pakket het documentpakket is met een version; unieke pakketidentificatoren; elke positie vermeldt referenceFrame FIXED of INERTIAL; bemonsterde posities zijn [t, x, y, z, ...] met een ISO 8601-epoch en oplopende tijden.
• KML: een goedgevormd XML-document (Extensible Markup Language) in de OGC KML 2,2-naamruimte met één rootfeature; de elementvolgorde van het schema binnen een Placemark; hoogstens één geometrie per Placemark; gesloten lineaire ringen van vier of meer posities; tupels lon,lat[,alt] binnen bereik; geldige waarden van altitudeMode; styleUrls die kunnen worden opgelost; een gx:Track met evenveel <when> als <gx:coord>, en de extensienaamruimte gedeclareerd.
• GeoJSON: lengtegraad eerst en binnen bereik, breedtegraad binnen bereik, twee of drie getallen per positie, lijnreeksen van twee of meer posities, gesloten buitenringen tegen de klok in, geen segment over de meridiaan van 180°, geen lid crs, een eigenschap units op elke feature.
• STK: de versieregel stk.v., een blok BEGIN Ephemeris / END Ephemeris met de vereiste trefwoorden, DistanceUnit Meters, NumberOfEphemerisPoints gelijk aan het aantal gegevensrijen, zeven getallen per rij, oplopende tijden.
• SigMF: core:datatype en core:version in global, arrays captures en annotations, core:sample_start bij elke capture, en een gegevensbestand met hele samples.

Naast de structuur wordt een satelliet die naar CZML en naar STK is geëxporteerd, vergeleken met de eigen toestand van de engine na dezelfde stelselreductie, en komt tot op 1 mm in positie overeen (de bestanden dragen 0,1 mm): met de eigen GCRS-uitvoer van het type ephemeris, en met een onafhankelijke TEME-naar-GCRS-propagatie van de constellatie orbit-sgp4-gps, waarbij elke satelliet wordt gedateerd met zijn eigen TLE-epoch uit de scenariotekst. Twee controles gaan buiten de engine: de CZML-posities van de eerste satelliet orbit-sgp4-gps komen tot op 0,1 m overeen (gemeten 2,3 cm) met dezelfde TLE gepropageerd door het Python-pakket sgp4 en door ERFA (Essential Routines for Fundamental Astronomy, de open implementatie van de SOFA-bibliotheek van de IAU) tot het GCRS gereduceerd, en de aardvaste posities van de satellieten orbit-rinex zijn gelijk aan de posities uit de uitgezonden efemeride van de interfacespecificatie van het Global Positioning System tot op 1 mm. De aardvaste posities van de export jamming worden vergeleken met de posities die de jammingrun beoordeelt, tot op 5 mm. De GeoJSON-route doorloopt een rondreis via een spoorscenario, het SigMF-paar leest terug naar dezelfde bytes, en elke export is byte-deterministisch.

Dit zijn controles tegen de gepubliceerde specificaties en tegen de engine zelf. De bestanden zijn als onderdeel van de testsuite niet in CesiumJS, Google Earth, Ansys STK of een SDR-hulpmiddel geladen, dus acceptatie door een bepaalde versie van die hulpmiddelen wordt hier niet getest.

Uitwisseling van baan-, standen- en kernelgegevens (bibliotheek, 0,36)#

Naast de formaten van --export voegde 0,36 bibliotheeklezers en -schrijvers toe voor de standaardbestanden die missieanalysehulpmiddelen uitwisselen. Ze nemen tekst of bytes aan en geven die terug en raken geen bestand aan. Elk is een rij VALIDATED van de verificatiematrix, tegen de daar genoemde onafhankelijke implementatie:

• CCSDS Orbit Data Messages (kshana::odm, met kshana::ndm_xml voor de XML-vorm): OPM, OMM en OCM in keyword-value-notatie (KVN) en NDM/XML, volgens CCSDS 502.0-B-3 (OPM en OMM versies 3,0 en 2,0, OCM 3,0). In beide richtingen gecontroleerd tegen Orekit: Orekit leest de bestanden van Kshana en Kshana leest die van Orekit. De bevindingen die overblijven, zijn met tests vastgepind.
• CCSDS Attitude Data Messages (kshana::adm, met kshana::ndm_xml): AEM en APM volgens CCSDS 504.0-B-2, in KVN en NDM/XML. Op dezelfde manier tegen Orekit gecontroleerd, en de recordrotaties tegen die van Orekit.
• SPICE SPK (kshana::spk_writer): schrijvers en lezers van NAIF-SPK-segmenten van de typen 9 en 13 (met de export van een CCSDS OEM naar een SPK-kernel) en de typen 3 en 21 (Chebyshev-polynomen en uitgebreide verschillijnen), gecontroleerd tegen de eigen lezers van de NAIF SPICE-toolkit, tot op byte-identiteit. Kshana schrijft de segmenten uit records die het krijgt: het past geen Chebyshev-coëfficiënten aan en produceert geen verschillijnen.

De CCSDS-OEM-importer en -schrijver en het OEM-covariantieblok zijn ouder en worden beschreven bij de imports hierboven en in de matrix.

Beperkingen#

• Alleen de typen in de tabel hieronder exporteren geometrie. Typen waarvan de geometrie op de Maan, Mars of een ander hemellichaam is gecentreerd, worden niet geëxporteerd: CZML, KML en GeoJSON beschrijven posities rond de aarde, en deze release schrijft STK-bestanden alleen met CentralBody Earth, hoewel het STK-formaat zelf andere centrale lichamen toestaat.
• constellation-design, earth-gnss-lunar en oem-interop hebben aardgerelateerde geometrie die deze release niet exporteert; de tabel geeft de reden voor elk.
• Het type gnss-ins vliegt zijn traject in een vlak lokaal raakvlak, dus alleen de oorsprong van het vlak wordt geëxporteerd, niet het traject.
• Aardvaste satellietposities verwaarlozen UT1−UTC en poolbeweging (zie Stelsels en tijd); KML-hoogten zijn ellipsoïdaal, niet boven gemiddeld zeeniveau.
• Voetafdrukken gaan uit van voortplanting in de vrije ruimte, een jammer aan de horizon van de ontvanger en een bolvormige aarde voor de cirkel.

Elk scenariobestand#

Wat kshana <scenario> --export <format> doet voor elk bestand in scenarios/ (het suitemanifest is geen scenario en blijft weg). "ja" betekent dat het formaat wordt geschreven en door zijn validator komt; anders verwijst het nummer naar de reden. Gegenereerd door cargo run --bin gen_validation_artifacts; tests/interop_formats.rs mislukt wanneer het verouderd is.

Waarom een formaat niet van toepassing is:

1. de typen contact-schedule en acm-link plannen downlinkcontacten en codering; exporteer een scenario passes voor dezelfde satelliet en hetzelfde station om de geometrie te zien
2. SigMF bevat complexe basisbandsamples, die alleen het type spectrum synthetiseert
3. het type aocs simuleert de stand om het massamiddelpunt zonder baan of grondpositie, dus er is niets om op de aarde te plaatsen
4. de scenarioinvoer bevat geen horizontale positie (geen breedte- en lengtegraad, geen aardgecentreerde coördinaten, geen baanelementen behalve hooguit een hoogte), dus er is niets om op de aarde te plaatsen
5. de typen eo-radiometry en ascent-losses berekenen budgetten zonder positie op aarde
6. een STK-efemeride beschrijft de positie en snelheid van een voertuig tegen de tijd; deze scène heeft alleen vaste punten of sporen zonder tijd (een vast punt is een STK Facility, geen efemeride)
7. geen lidscenario van de campagne heeft iets wat dit formaat beschrijft; exporteer een lid afzonderlijk om de reden te zien
8. het type leo-signal analyseert signaalontwerpen (spectra, tracking, acquisitie, compatibiliteit) zonder satelliet- of gebruikerspositie; exporteer het scenario leo-pass of leo-pnt-chain dat het ontwerp vliegt
9. niet geëxporteerd in deze release: de typen voor gefuseerde positiebepaling plaatsen hun satellieten in een aardvast stelsel ten opzichte van een epoch die ze nooit noemen, dus een export met tijdlabels zou de kalenderdatum moeten verzinnen (exporteer in plaats daarvan het scenario leo-pass of leo-pnt-chain)
10. de geometrie van het type is gecentreerd op de Maan, Mars of een ander lichaam van het zonnestelsel; CZML, KML en GeoJSON beschrijven posities op of rond de aarde, en deze release schrijft STK-efemeriden alleen met CentralBody Earth
11. niet geëxporteerd in deze release: constellation-design plaatst zijn satellieten in een lichaamsvast stelsel ten opzichte van een epoch die het nooit noemt, dus een export met tijdlabels zou de kalenderdatum moeten verzinnen
12. niet geëxporteerd in deze release: de aardse constellatie van het Global Navigation Satellite System (GNSS) van earth-gnss-lunar wordt gezien vanaf een ontvanger op maanafstand, wiens traject het type niet als tijdreeks beschikbaar stelt
13. niet geëxporteerd in deze release: het type entry-heating rapporteert piekbelastingen en verhitting, en houdt geen grondspoor met tijdlabels bij
14. het type gnss-ssv sweept beschikbaarheid en linksterkte voor een gebruiker op een schil of een Kepler-traject; het heeft geen enkele positie om op een kaart te plaatsen
15. het scenario launch-window geeft de breedtegraad van de lanceerlocatie maar geen lengtegraad, dus de locatie kan niet worden geplaatst
16. niet geëxporteerd in deze release: de referentiebaan van leo-navmsg is een fitreferentie waarvan de aardrotatiehoek op het epoch een invoer is (theta0_deg, standaard 0), niet afgeleid van de kalenderdatum, dus zijn aardvaste posities zijn niet aan een datum gebonden
17. dit spectrumscenario heeft geen blok [iq], dus er worden geen samples gesynthetiseerd om op te nemen
18. niet geëxporteerd in deze release: oem-interop leest en schrijft een CCSDS-Orbit Ephemeris Message (Consultative Committee for Space Data Systems), die zelf het uitwisselingsbestand voor efemeriden is
19. het type optical-atmosphere berekent linkstatistieken voor grondlocaties zonder geometrie met tijdlabels om te plaatsen
20. het scenario sweept een ander scenario over een raster; exporteer het gesweepte scenario afzonderlijk
21. het type time-transfer-budget berekent een linkbudget en stabiliteiten, zonder geometrie met tijdlabels om te plaatsen