holdover-test (scenariotype)

Scenariotype i motoren v0.40.0, familie Klokker, tidssynkronisering og holdover. Veiledende: analyseutdata fra et forsknings- og ingeniørverktøy, ikke typegodkjent navigasjonsutstyr og ikke en sikkerhetskritisk tjeneste for menneskeliv. Hver etikett her er motorens eller verifikasjonsmatrisens; en type er MODELLED med mindre matrisen sier noe annet (hvordan en etikett fortjenes: Evidens-avsnittet i README).

Hva den gjør#

MODELLED holdover-test av et system for tidssynkronisering, vurdert ut fra en tidsfeilregistrering som OPERATØREN leverer (en linuxptp ptp4l-, phc2sys- eller ts2phc-logg, en chrony tracking- eller statistikklogg, en TICC-, TimeLab- eller RINEX-klokkelogg, eller par av time_s,time_error_ns). Testen har fire trinn, og Kshana utfører ingen av dem: en låst GRUNNLINJE, GNSS FJERNET av operatøren (antennekabelen eller simulatorutgangen; Kshana sender ingenting og styrer ingenting) på et oppgitt tidspunkt, HOLDOVER på systemets egen oscillator, og GJENOPPRETTING etter at operatøren har gjenopprettet GNSS på et andre oppgitt tidspunkt. Registreringen deles ved disse to tidspunktene. Grunnlinje: tidsfeilstatistikk og ITU-T-maskene skrevet for en låst klokke. Holdover: statistikk, den relative frekvensavviket systemet holdt (en minstekvadraters linje), maskene skrevet for holdover eller en autonom klokke, ePRTC-A-holdoverenvelopen fra den oppgitte låste varigheten, og tiden til hvert tidsfeilbudsjett overskrides. Gjenoppretting: om og når |TE| kom innenfor et oppgitt bånd og ble der, toppen og det største trinnet. Hver grense er avskrevet fra en offentlig ITU-T-tabell (maskene for tidssynkronisering i telekommunikasjon); ordlyden er 'målt mot masken', og de to tidspunktene er operatørens opplysning, ikke verifisert. En registrering som er for kort for en maske er INCOMPLETE, aldri ekstrapolert. Se docs/TIMING-HIL.md.

Én kjøring av scenarios/holdover-test-ptp4l.toml oppsummeres slik: holdover-test: holdover 1795 s, max|TE| 59,0 ns; prtc-a PASS, eprtc-a-holdover FAIL; recovered 0 s after GNSS returned (MODELLED, measured against the mask)

Inndata#

Fra skjemaet (kshana kinds --json):

• Obligatoriske felt: test, series
• Valgfrie felt: masks, budgets

Eksemplet scenarios/holdover-test-ptp4l.toml setter blant annet:

Kjør den#

kshana scenarios/holdover-test-ptp4l.toml

2 medfølgende scenarioer bruker denne typen; de andre står i scenarios/.

Hva den gir#

Skalarresultatene fra den kjøringen, med enhetene motoren oppgir:

Resultatetikett (motorens): MODELLED — en holdover-test vurdert ut fra en tidsfeilregistrering operatøren har levert. Hver grense er avskrevet fra den navngitte offentlige ITU-T-anbefalingen, og resultatet er målt mot masken; det sier ingenting om hvorvidt noen klokke eller noe system tilfredsstiller en anbefaling, og ingen har vurdert eller godk

Evidens#

MODELLED: radene i verifikasjonsmatrisen som navngir denne typen.

• MODELLED Typen holdover-test: en tidsfeilregistrering (en linuxptp-, chrony-, TICC-, TimeLab- eller RINEX-klokkelogg, eller par av time_s,time_error_ns) deles ved de to tidspunktene operatøren oppgir for fjerning og gjenoppretting av GNSS i en grunnlinje, en holdover a

Radene kjøringen selv brukte, med den uavhengige referansen matrisen gir hver (de offentlige kildene er navngitt der):

• MODELLED Deterministisk, scenariohashet, SBOM + gates med gylne verdier på tvers av plattformer. Uavhengig referanse (ExternalDataset): SBOM-overensstemmelse med det offisielle CycloneDX 1,5 JSON Schema (+ gyldige SPDX-identifikatorer), en ekstern publisert standard, null valideringsfeil over hele avhengighetsgrafen; delen om FoM-determinisme / byte-reproduserbarhet er fortsatt en festet selvkonsistenssjekk, så raden forblir MODELLED
• VALIDATED Maksimal tidsintervallfeil og tidsavvik som scenariotypen telecom-timing rapporterer, på en holdover-registrering i telekommunikasjonsskala: en O(n) monoton kø-glidende. Uavhengig referanse (ExternalDataset): allantools 2024,06, et uavhengig tredjeparts bibliotek for frekvensstabilitet, mtie() og tdev() på tests/fixtures/telecom_timing/holdover_te_series.csv, serien tolket fra den samme teksten med 17 gjeldende sifre på begge sider; referansen registrerer seriens SHA-256 og kan gjenskapes frakoblet via tests/fixtures/telecom_timing/generate_telecom_timing_reference.py. Validerer ESTIMATORENE på denne registreringen, ikke syn
• MODELLED Avskrevne grenser fra ITU-T G.8272 (07/2025) PRTC-A/B, G.8272.1 (2024) Amd. 1 (07/2025) ePRTC låst og ePRTC-A holdover (inkludert tidsfeilenvelopen i tabell 3. Uavhengig referanse (InternalConsistency): Avskrift av de navngitte anbefalingene (fritt tilgjengelige på itu.int), der hver grense bærer sin tabell eller sin klausul, oppført sammen med hvert ubekreftet eller uimplementert punkt i docs/TELECOM-TIMING.md; identitetene for kontinuitet i knekkpunktene som tabellene medfører, kontrolleres i testene. En standardavskrift med interne konsistenskontroller, ikke en test av overensstemmelse og ikke en ekstern validering. 0,30 runde 2 (forhåndsregistrert
• MODELLED Typen holdover-test: en tidsfeilregistrering (en linuxptp-, chrony-, TICC-, TimeLab- eller RINEX-klokkelogg, eller par av time_s,time_error_ns) deles ved de to tidspunktene. Uavhengig referanse (InternalConsistency): Håndberegning på registreringer bygd fra formler der stigning, trinn, ekstremum og gjenopprettingstid er kjent før kjøringen (testene oppgir dem), og maskene, envelopen og budsjettene i radene for tidssynkronisering i telekommunikasjon ovenfor. Ingen laboratoriemåling av en virkelig holdover er vurdert og ingen ekstern uavhengig referanse er sammenlignet, så typen fremsetter ingen påstand om noen klokke eller noe system; en partner med tidslaboratorium trengs før noen per-klokkeklasse fi

Begrensninger#

Hva kjøringens egen rapport sier ikke er modellert eller ikke er validert:

• MODELLED — en holdover-test vurdert ut fra en tidsfeilregistrering operatøren har levert. Hver grense er avskrevet fra den navngitte offentlige ITU-T-anbefalingen, og resultatet er målt mot masken; det sier ingenting om hvorvidt noen klokke eller noe system tilfredsstiller en anbefaling, og ingen har vurdert eller godkjent det. Tidspunktene da GNSS ble fjernet og gjenopprettet er operatørens opplysning og er ikke verifisert. Veiledende programvare (resultat label)
• MODELLED holdover-test av et system for tidssynkronisering, vurdert ut fra en tidsfeilregistrering som OPERATØREN leverer (en linuxptp ptp4l-, phc2sys- eller ts2phc-logg, en chrony tracking- eller statistikklogg, en TICC-, TimeLab- eller RINEX-klokkelogg, eller par av time_s,time_error_ns). (typekatalog (kshana kinds --json))
• Reproduserbarhet og programvarekvalitetssikring er MODELLED, ikke validert: en delpåstand er kontrollert eksternt, men hele funksjonen setter sammen modellerte deler, så funksjonen forblir modellert. (verifikasjonsmatrise (docs/MODELLED-RATIONALE.md))
• ITU-T-masker for tidssynkronisering i telekommunikasjon med PASS/FAIL og margin er MODELLED, ikke validert: kontrollert mot sin egen lukkede/analytiske identitet, noe som fanger opp transkripsjons- og koeffisientfeil, men ikke er en ekstern uavhengig referanse. (verifikasjonsmatrise (docs/MODELLED-RATIONALE.md))
• Holdover-test vurdert ut fra en tidsfeilregistrering levert av operatøren er MODELLED, ikke validert: kontrollert mot sin egen lukkede/analytiske identitet, noe som fanger opp transkripsjons- og koeffisientfeil, men ikke er en ekstern uavhengig referanse. (verifikasjonsmatrise (docs/MODELLED-RATIONALE.md))

Se også#

• Familieside: Klokker, tidssynkronisering og holdover
• Alle typer: KINDS.md
• Temaside: TIMING-HIL.md
• Temaside: HARDWARE-SAFETY.md