Der Beispielfall: Rückverfolgung der Empfehlung zu ihren Nachweisen
Verfolgen Sie das synthetische Begehren von Tessera Compute vom eingereichten Antrag bis zu den Nachweisen hinter der Upgrade study-Empfehlung. Die Gegenbeispiele zeigen, warum Prüfungsreife, thermische Auswirkungen und Studienpriorität separate Erklärungen erfordern. Alle Anträge und das Netz sind synthetisch; in Screenshots sichtbare Firmennamen der Antragsteller sind Test-Labels, keine Kunden, Implementierungen oder Empfehlungen.
Wählen Sie einen beliebigen Screenshot aus, um das Original in voller Größe zu öffnen. Dies sind Produkt-Screenshots; die abgebildeten Steuerelemente gehören zum aufgezeichneten lokalen Arbeitsbereich.
Den Nachweisen folgen
Das Begehren prüfen, bevor man seiner Empfehlung vertraut
Tessera beantragt 750 MW am Netzanschlusspunkt Bus 3. Der eingereichte Text beschreibt Flächensicherung (site control) und geleistete Studienanzahlungen. Die Quellansicht ermöglicht es einem Prüfer, diese Angaben mit den extrahierten Feldern abzugleichen, anstatt die Vollständigkeit aus einem Projektnamen oder der beantragten Kapazität abzuleiten.
Die Intake-Ansicht erfasst eine bestätigte Flächensicherung und eine hinterlegte Studienanzahlung. Diese Eingaben fließen in einen Reifewert von 0.92 ein, dargestellt als 92 von 100. Dies ist eine konfigurierte Priorisierungsheuristik, keine Wahrscheinlichkeit eines erfolgreichen Netzanschlusses, keine Bonitätsprüfung und kein Nachweis ingenieurtechnischer Machbarkeit.
Die optionale modellgestützte Antragsaufnahme liefert eine zusätzliche Extraktion zum Abgleich mit der Quelle. Die Video-Demonstration verwendet eine gespeicherte reale Modellantwort wieder. Dieses beratende Ergebnis kann weder die gespeicherte Warteschlangenempfehlung noch die Studienreihenfolge ändern, und der vollständige Warteschlangenlauf nutzt das Modell nicht. Ein Prüfer muss extrahierte Felder weiterhin gegen den eingereichten Antrag abgleichen.
Das vom Screening tatsächlich abgedeckte Netz definieren
Der synthetische Testfall umfasst 2.000 Busse und 3.633 Zweige. Das Screening überwacht 976 nicht-radiale Übertragungszweige, deren beide Enden auf 138 kV oder höher liegen. Power transfer distribution factors schätzen ab, wie eine Einspeisung die Leitungsflüsse verändert; line outage distribution factors schätzen die Leitungsflüsse der verbleibenden Leitungen nach dem Ausfall einer überwachten Leitung.
Die angeforderte MW-Leistung wird als eine an einem Slack Bus ausgeglichene Einspeisung behandelt (slack-balanced injection), einschließlich Begehren, die als Großlasten gekennzeichnet sind. Dies ist eine illustrative Modellierungskonvention, keine validierte Lastentnahmestudie. Bestehende Basis-Überlastungen sind von der Projektzurechnung ausgeschlossen; das Fehlen neuer Projektengpässe beweist daher nicht, dass das gesamte Netz sicher ist.
Den Ausfall identifizieren, der den Studienpfad ändert
Tesseras schlechteste zurechenbare Basisfall-Auslastung liegt bei 92.3% und damit unter dem thermischen Grenzwert von 100%. Nach dem Ausfall einer einzelnen überwachten Leitung erreicht die schlechteste zurechenbare Auslastung 112.4%. Die Empfehlung lautet daher Upgrade study, obwohl der Antrag prüfungsreif ist und der Basisfall unter dem Grenzwert bleibt.
Die entscheidende Prüffrage lautet: Welches Element wird bindend, unter welchem Ausfall, und ist die Überlastung dem Begehren neu zuzurechnen? Das Schaltschema liefert den Anschlusskontext; der benannte Zweig, der Ausfallfall und die Auslastung liefern die ausschlaggebenden thermischen Nachweise. Ein Upgrade study-Pfad erfordert weiterführende Ingenieurarbeiten, anstatt einen bestimmten Bauentwurf zu genehmigen.
Vergleich eines unauffälligen Screenings mit einer Grenzfallprüfung
Das synthetische Projekt Apex DC beantragt ebenfalls 750 MW und weist eine Prüfungsreife von 0.92 auf. Seine schlechteste zurechenbare Basisauslastung liegt bei 79.7% und die Einzelausfall-Auslastung bei 96.4%, ohne neue Überlastung. Es erhält ein Clean screen: Übergang zur detaillierten Netzanschlussstudie. Diese Einstufung stellt keine Anschlussgenehmigung dar.
Synthetisches Cortex Compute weist ebenfalls keine neue Überlastung auf, doch seine Einzelausfall-Auslastung von 96.7% stellt eine neue Überschreitung des 95%-Warnbands dar. Die konfigurierte Richtlinie leitet diesen Grenzfall in die Engineering review weiter. Ein Wert unterhalb des Überlastungsgrenzwerts kann daher dennoch eine fachliche Beurteilung erfordern, und ein Prüfpfad ist keine abgeschlossene Ingenieurentscheidung.
Netzausbau von unvollständiger Antragsaufnahme unterscheiden
Das synthetische Projekt Stargate Compute beantragt 500 MW und erreicht eine schlechteste zurechenbare Basisauslastung von 163.6%. Es wird einer Major network build-Studie zugewiesen. In dieser Konfiguration löst eine Auslastung von über 135% oder mehr als vier neue Engpasseinträge diesen Pfad aus. Die Einstufung kennzeichnet einen Studienbedarf; sie begründet weder einen Rechtsverstoß noch einen fertigen Verstärkungsentwurf.
Synthetisches Helios Compute hat ein anderes Problem. Seinem Antrag fehlen eine rechtsgültige Flächensicherung und eine hinterlegte Anzahlung; frühere Rücknahmen sowie eine Anpassung für Mantelgesellschaften oder Zweckgesellschaften senken den konfigurierten Reifewert zudem auf 0.00. Das Projekt rückt von Eingangsposition 1 auf First-ready-Position 213 vor und verbleibt für die weitere Antragsaufnahme in der Warteschlange.
Ungeklärte Anschlusspunkte, eine Extraktionskonfidenz unter 0.60 und nicht verfügbare physikalische Berechnungen leiten Begehren ebenfalls in die Engineering review. Dadurch bleibt der Unterschied zwischen fehlenden Nachweisen und einer bestandenen Prüfung gewahrt. Jede Empfehlung benötigt ihre Begründung; ein einzelner Gesamtwert würde verschleiern, ob die nächste Maßnahme die Antragsaufnahme, die thermische Analyse oder das ingenieurtechnische Urteil betrifft.
Den Studienreihenfolge-Vergleich lesen, ohne Positionen mit Zeit zu verwechseln
| Studienempfehlung | Synthetische Anträge | Interpretation |
|---|---|---|
| Clean screen | 84 | Keine neue zurechenbare Überlastung und keine konfigurierte Prüfbedingung. |
| Upgrade study | 22 | Neue zurechenbare Überlastung erfordert Upgrade study. |
| Engineering review | 30 | Ungeklärte Nachweise, nicht verfügbare physikalische Berechnungen oder marginale Auslastung. |
| Major network build | 24 | Konfigurierter Studienpfad für größere Netzverstärkungen. |
| Low readiness | 90 | Weitere Antragsaufnahme vor prioritärer Studie erforderlich. |
Die Pfade Clean screen und Upgrade study umfassen zusammen 106 Anträge und rund 62.2 GW an beantragter Kapazität. Die Benutzeroberfläche bezeichnet dies als prüfungsbereite Kapazität (study-ready capacity). Da sie auch Begehren enthält, die Netzausbauten erfordern, ist dies keine verfügbare oder anschlussfähige Kapazität. Das Clustering nach elektrischer Nähe fasst nur diese beiden Pfade zusammen; es klärt weder die regulatorische Eignung noch schließt es eine kombinierte Ingenieurstudie ab.
Die First-ready-Reihenfolge sortiert nach Empfehlungspriorität, absteigender Prüfungsreife und anschließend absteigender MW-Zahl. Über die 106 Clean-screen- und Upgrade-study-Anträge hinweg ändert sich die exakte mediane Position von 138.5 auf 53.5; die Oberfläche schneidet diese Mediane ab. Tessera rückt von Position 9 auf 92 vor, während es seinen Upgrade study-Pfad beibehält, was zeigt, dass die Prüfungsreife allein nicht die Priorität bestimmt.
Die sichtbare Kennzahl für die Restudy-Exposition zählt vorgelagerte Low-readiness- oder Major-build-Begehren einmal für jeden nachfolgenden Clean-screen- oder Upgrade-study-Antrag. Sie sinkt von 6,596 auf null, da die konfigurierte Sortierung diese vorgelagerten Pfade nach hinten verschiebt. Sie simuliert weder tatsächliche Neuberechnungen, Rücknahmen, verstrichene Zeit, Netzausbaufertigstellungen noch ingenieurtechnischen Aufwand, und dieser Vergleich stellt keine Optimierungs- oder Fairnessgarantie dar.
Prüfungen inspizieren und den exakten Studiendatensatz sichern
Der Laufzeit-Benchmark trennt sechs physikalische Identitätsprüfungen von sechs expliziten Richtlinienfällen. Die physikalischen Prüfungen testen numerische Beziehungen; die Richtlinienfälle testen konfigurierte Routing-Grenzen. Der erfasste Durchlauf meldet, dass alle zwölf Prüfungen bestanden wurden. Dies ist ein Implementierungsnachweis auf einer festen synthetischen Testsuite, keine Aussage über Feldgenauigkeit, vollständige Netzmachbarkeit oder unabhängige Validierung.
Ein laufspezifischer Studienplan-Export als JSON sichert die Warteschlangennachweise, während die druckbare Projekt-HTML-Datei die Studienidentität, die Antragsaufnahme, die Empfehlung und die ausschlaggebenden Engpässe für einen einzelnen Antrag enthält. Benchmark-JSON-Dateien sichern die beobachteten Prüfungen separat. Diese Datensätze ermöglichen es einem Prüfer festzustellen, welcher Lauf eine Aussage stützt, anstatt sich auf einen isolierten Screenshot zu verlassen.
Heruntergeladene Dateien bleiben erhalten, nachdem Serverläufe ablaufen. Der lokale Arbeitsbereich speichert höchstens sechzehn aktuelle Läufe im Arbeitsspeicher; abgeschlossene Läufe laufen eine Stunde nach ihrer Erstellung ab und werden durch einen Server-Neustart gelöscht. Ein produktiver Einsatz würde separate Entscheidungen über validierte Netzdaten, dauerhafte Datensätze, Zugriffskontrollen, Ingenieurbefugnisse und die über dieses Screening hinaus erforderlichen Studien erfordern.
