Merge pull request 'Automotive convergence stress test (Phase Omega #2)' (#37) from feat/automotive-convergence-stress-test into main
This commit is contained in:
pilotadmin
@@ -76,6 +76,16 @@ sources:
|
||||
integration_kind: data_only
|
||||
family: non_cyber # FIRST non-cyber domain — the real generality test
|
||||
exercised_by: "customer_mission_5, environmental_stress_test"
|
||||
- source: "Automotive ECU for OEM X (CRA / UNECE R155+R156 / IATF 16949 / TISAX / ASPICE / OEM spec)"
|
||||
domain: automotive
|
||||
target_type: multi_source # 7 OVERLAPPING sources spanning regulation + certification + process + contract
|
||||
integrated_as: multi_source_required_set
|
||||
new_runtime_classes: 0
|
||||
new_pipeline: false
|
||||
new_capability_types: 14 # of 27 required caps, 13 reuse existing MCAPs (48% -> registry converging)
|
||||
integration_kind: data_only
|
||||
family: cyber # convergence test: same capability fed by many sources, model stayed stable
|
||||
exercised_by: "automotive_convergence_stress_test"
|
||||
|
||||
# --- One-time, domain-AGNOSTIC pipeline functions (built once, now FROZEN per Phase Ω). ---
|
||||
# Listed for honesty so the stability KPI cannot be gamed: these are NOT per-domain costs. The last
|
||||
|
||||
@@ -0,0 +1,58 @@
|
||||
# Automotive multi-source capability data — the CONVERGENCE stress test (Phase Ω, test #2).
|
||||
#
|
||||
# Not another domain to validate domain-agnosticism (Environmental already proved that). This tests a
|
||||
# DIFFERENT property: can the SAME capability be fed by MANY different Requirement Sources at once
|
||||
# without the model becoming unstable? Realistic setup: a supplier developing an ECU for OEM X, who
|
||||
# already holds ISO 9001 + IATF 16949 + TISAX + ASPICE (L2/3) + CSMS + SUMS.
|
||||
#
|
||||
# Each source lists the capabilities it REQUIRES. Overlap is deliberate and realistic — that overlap is
|
||||
# exactly where the economic value lives ("one capability replaces five evidence worlds"). Capabilities
|
||||
# are VERBS / stable ids reused from the cyber + environmental patterns where they recur, so the
|
||||
# existing-vs-new (registry convergence) measurement is honest. Data only — no runtime code.
|
||||
|
||||
goal: "Develop a new ECU (Steuergerät) and supply OEM X."
|
||||
|
||||
sources:
|
||||
- id: CRA
|
||||
type: regulation
|
||||
requires: [secure_signed_update_distribution, technical_vulnerability_management,
|
||||
coordinated_vulnerability_disclosure, sbom_creation, access_control_and_authentication,
|
||||
incident_management, secure_development_lifecycle, product_cyber_risk_assessment]
|
||||
- id: UNECE_R155_CSMS
|
||||
type: regulation
|
||||
requires: [secure_signed_update_distribution, technical_vulnerability_management,
|
||||
product_cyber_risk_assessment, incident_management, access_control_and_authentication,
|
||||
cybersecurity_management_system, threat_analysis_and_risk_assessment]
|
||||
- id: UNECE_R156_SUMS
|
||||
type: regulation
|
||||
requires: [secure_signed_update_distribution, software_update_management_system,
|
||||
identify_software_versions_rxswin, document_update_campaigns]
|
||||
- id: IATF_16949
|
||||
type: certification
|
||||
requires: [document_and_change_control, supplier_evaluation, release_and_approval_process,
|
||||
approve_production_parts_ppap, plan_product_quality_apqp]
|
||||
- id: TISAX
|
||||
type: certification
|
||||
requires: [information_security_management, access_control_and_authentication, incident_management,
|
||||
technical_vulnerability_management, supplier_security, protect_prototypes]
|
||||
- id: ASPICE
|
||||
type: process
|
||||
requires: [assess_software_process_capability, engineer_requirements_process,
|
||||
verify_software_process, manage_configuration_process]
|
||||
- id: OEM_X_Spec
|
||||
type: contract
|
||||
requires: [secure_signed_update_distribution, technical_vulnerability_management,
|
||||
provide_functional_safety_evidence, protect_prototypes, supplier_security,
|
||||
identify_software_versions_rxswin, provide_dedicated_security_contact]
|
||||
|
||||
# The company's certificates/processes -> the capabilities they make probably-present (Welt-1).
|
||||
# (Management/process discipline + the security baseline an automotive supplier with these certs has.)
|
||||
company_profile_capabilities:
|
||||
ISO9001: [document_and_change_control, supplier_evaluation, release_and_approval_process]
|
||||
IATF16949: [approve_production_parts_ppap, plan_product_quality_apqp]
|
||||
TISAX: [information_security_management, access_control_and_authentication, incident_management,
|
||||
technical_vulnerability_management, supplier_security, protect_prototypes]
|
||||
ASPICE: [assess_software_process_capability, engineer_requirements_process,
|
||||
verify_software_process, manage_configuration_process]
|
||||
CSMS: [cybersecurity_management_system, threat_analysis_and_risk_assessment, product_cyber_risk_assessment]
|
||||
SUMS: [software_update_management_system, document_update_campaigns]
|
||||
@@ -12,11 +12,12 @@ _Der Fokus hat sich verschoben: nicht mehr „kann die Architektur das?", sonder
|
||||
| Public Tender (öffentliche Ausschreibung) | cyber | 0 | 0 | 3 | ✅ |
|
||||
| OEM Specification (Lastenheft) | cyber | 0 | 0 | 4 | ✅ |
|
||||
| ISO 14001 -> Environmental/Material (REACH/RoHS/Batterie/Wasser/Energie/Abfall) | non_cyber | 0 | 0 | 16 | ✅ |
|
||||
| Automotive ECU for OEM X (CRA / UNECE R155+R156 / IATF 16949 / TISAX / ASPICE / OEM spec) | cyber | 0 | 0 | 14 | ✅ |
|
||||
|
||||
- **Architecture Stability: 6/6 = 100%** der Quellen ohne neue Runtime-Klasse und ohne neue Pipeline.
|
||||
- **Knowledge Velocity: 6/6 = 100%** der Quellen **data-only** integriert (kein Entwickler nötig).
|
||||
- **Generalität über Cyber hinaus: 1/6 Quellen NICHT-Cyber** (Umwelt) — trugen die Pipeline ebenfalls 0/0. Das ist der eigentliche Test (ein anderes Denkmodell, nicht noch ein Cyber-Regelwerk).
|
||||
- **Capability-Modell-Frühindikator: 45 neue Typen gesamt, Maximum 16** (Umwelt, erste Nicht-Cyber-Domäne) — in Range, KEIN Granularitätsalarm (Alarm ≈ eine Domäne braucht plötzlich ~80 neue Typen bei 0 Runtime-Change → Modell zu grob/fein).
|
||||
- **Architecture Stability: 7/7 = 100%** der Quellen ohne neue Runtime-Klasse und ohne neue Pipeline.
|
||||
- **Knowledge Velocity: 7/7 = 100%** der Quellen **data-only** integriert (kein Entwickler nötig).
|
||||
- **Generalität über Cyber hinaus: 1/7 Quellen NICHT-Cyber** (Umwelt) — trugen die Pipeline ebenfalls 0/0. Das ist der eigentliche Test (ein anderes Denkmodell, nicht noch ein Cyber-Regelwerk).
|
||||
- **Capability-Modell-Frühindikator: 59 neue Typen gesamt, Maximum 16** (Umwelt, erste Nicht-Cyber-Domäne) — in Range, KEIN Granularitätsalarm (Alarm ≈ eine Domäne braucht plötzlich ~80 neue Typen bei 0 Runtime-Change → Modell zu grob/fein).
|
||||
|
||||
## Ehrlichkeit: die Pipeline-Funktionen sind EINMALIG (jetzt eingefroren)
|
||||
- 6 domänen-AGNOSTISCHE Funktionen, einmal gebaut, nicht je Domäne: `transition_reasoning (RS-005)`, `optimization`, `journey_matcher (ADR-011)`, `playbook`, `completeness`, `company (2A)`.
|
||||
@@ -30,8 +31,8 @@ _Der Fokus hat sich verschoben: nicht mehr „kann die Architektur das?", sonder
|
||||
| **Produktion** (wie TUN/BEWEISEN) | Playbooks, Verification, Reference Scenarios |
|
||||
|
||||
## Die drei Erfolgsfragen ab jetzt (statt Coverage)
|
||||
1. **Musste für eine neue Domäne Runtime-Code geändert werden?** → bisher: **nein** (6/6).
|
||||
2. **Knowledge Velocity** — neues Wissen ohne Entwickler aufnehmbar? → bisher: **ja** (6/6 data-only).
|
||||
1. **Musste für eine neue Domäne Runtime-Code geändert werden?** → bisher: **nein** (7/7).
|
||||
2. **Knowledge Velocity** — neues Wissen ohne Entwickler aufnehmbar? → bisher: **ja** (7/7 data-only).
|
||||
3. **Architecture Stability** — bestehende Capability/Journey strukturell ändern oder nur Daten ergänzen? → bisher: **nur Daten**.
|
||||
|
||||
> **Befund:** Über fünf Zielarten und sechs Quellen blieb `Reality → Evidence → Capability → Required → Delta → Journey → Roadmap → Playbooks → Verification` unverändert. Das ist der eigentliche Nachweis: keine Compliance-Architektur, sondern eine allgemeine Requirements-Verifikationsarchitektur, die ihre Generalität UNTER realer fachlicher Belastung behält. Der nächste Test ist nicht ein Feature, sondern die nächste echte Domäne (Umwelt-Cluster · Automotive · Medizintechnik · Payment) — jede als neue Ledger-Zeile, bei stabilem KPI.
|
||||
|
||||
@@ -0,0 +1,36 @@
|
||||
# Automotive Convergence Stress Test — überlebt EINE Capability viele Quellen? (Phase Ω #2)
|
||||
|
||||
_Nicht noch eine Domäne, sondern eine andere Eigenschaft: bleibt das Modell stabil, wenn dieselbe Capability gleichzeitig aus vielen überlappenden Quellen gespeist wird? Realistisch: ein Zulieferer (ISO 9001 + IATF 16949 + TISAX + ASPICE + CSMS + SUMS) entwickelt ein Steuergerät für OEM X. Sieben Quellen, bewusste Überlappung. Data-only, keine echten Namen._
|
||||
|
||||
## 1. Sieben überlappende Quellen, eine Engine
|
||||
- Quellen: `CRA`(regulation), `UNECE_R155_CSMS`(regulation), `UNECE_R156_SUMS`(regulation), `IATF_16949`(certification), `TISAX`(certification), `ASPICE`(process), `OEM_X_Spec`(contract).
|
||||
- **27 distinct geforderte Capabilities** für „Steuergerät → OEM X" — über dieselbe `assess_transition`-Engine, 0 neue Runtime-Klassen.
|
||||
- Delta (fehlt dem Profil): **7** Capabilities.
|
||||
|
||||
## 2. Capability Convergence — dieselbe Capability aus vielen Quellen
|
||||
| Capability | Sources | Distinct Source Types | aus |
|
||||
|---|---:|---:|---|
|
||||
| `technical_vulnerability_management` | 4 | 3 | CRA, OEM_X_Spec, TISAX, UNECE_R155_CSMS |
|
||||
| `secure_signed_update_distribution` | 4 | 2 | CRA, OEM_X_Spec, UNECE_R155_CSMS, UNECE_R156_SUMS |
|
||||
| `access_control_and_authentication` | 3 | 2 | CRA, TISAX, UNECE_R155_CSMS |
|
||||
| `incident_management` | 3 | 2 | CRA, TISAX, UNECE_R155_CSMS |
|
||||
| `identify_software_versions_rxswin` | 2 | 2 | OEM_X_Spec, UNECE_R156_SUMS |
|
||||
| `protect_prototypes` | 2 | 2 | OEM_X_Spec, TISAX |
|
||||
| `supplier_security` | 2 | 2 | OEM_X_Spec, TISAX |
|
||||
| `product_cyber_risk_assessment` | 2 | 1 | CRA, UNECE_R155_CSMS |
|
||||
|
||||
→ **`technical_vulnerability_management`** ist am konvergentesten: **4 Quellen** über **3 Quelltypen** — eine Maßnahme, viele Nachweiswelten. Genau hier entsteht der wirtschaftliche Nutzen (nicht „300 Gesetze", sondern „eine Capability ersetzt fünf Nachweiswelten").
|
||||
|
||||
## 3. Existing-vs-New — beginnt die Registry zu konvergieren?
|
||||
- **Bereits vorhandene MCAPs (Reuse aus Cyber/Umwelt): 13/27 = 48%** — z. B. `access_control_and_authentication`, `coordinated_vulnerability_disclosure`, `document_and_change_control`, `incident_management`, `information_security_management` ….
|
||||
- **Genuin neu (Automotive-spezifisch): 14** — z. B. `approve_production_parts_ppap`, `assess_software_process_capability`, `cybersecurity_management_system`, `document_update_campaigns`, `engineer_requirements_process` ….
|
||||
- **Lesart:** Spürbare Wiederverwendung (48%) — der Kern beginnt sich zu bilden; der automotive-spezifische Rest (CSMS/SUMS/ASPICE/Funktionssicherheit) ist erwartbar neu. Kein Architekturbruch, sondern ein Hinweis auf den Reifegrad der Capability-Zerlegung.
|
||||
|
||||
## 4. Business Leverage — Märkte + Regulierung, nicht nur „Gesetze"
|
||||
- `technical_vulnerability_management` erfüllt gleichzeitig **2 Regelwerke** (CRA, UNECE_R155_CSMS) **und** öffnet den **OEM-Markt** (OEM_X_Spec).
|
||||
- Managementsatz: **„Diese eine Capability erfüllt 2 regulatorische Anforderungen UND ist Eintrittskarte zum OEM-Geschäft"** — überzeugender als „erfüllt 2 Gesetze". (Regulatory Leverage zählt Regelwerke; **Business Leverage** zählt Regelwerke + erschlossene Märkte/Kunden.)
|
||||
|
||||
## Befund
|
||||
|
||||
> **Eine Capability aus bis zu 4 Quellen über 3 Quelltypen — das Modell blieb stabil (0 neue Runtime-Klassen, 0 neue Pipeline; reine Daten).** Convergence ist messbar geworden, und 48% der Automotive-Anforderungen bilden auf BESTEHENDE MCAPs ab — die Registry beginnt zu konvergieren. Nächster Schritt ist bewusst KEINE neue Domäne, sondern **innehalten und die Registry analysieren**: welche MCAPs tauchen domänenübergreifend (CRA·MaschinenVO·OEM·TISAX·ASPICE·Umwelt) am häufigsten auf? Diese hochkonvergenten Capabilities sind der dauerhaft wertvollste Plattformkern.
|
||||
|
||||
@@ -0,0 +1,127 @@
|
||||
# ruff: noqa
|
||||
# mypy: ignore-errors
|
||||
"""Automotive convergence stress test — does the SAME capability survive MANY sources? (Phase Ω, test #2)
|
||||
|
||||
Environmental proved domain-agnosticism. This tests a different property: can ONE capability be fed by
|
||||
many overlapping Requirement Sources at once without the model becoming unstable? Realistic setup — a
|
||||
supplier with ISO 9001 + IATF 16949 + TISAX + ASPICE + CSMS + SUMS developing an ECU for OEM X. Seven
|
||||
sources (CRA, UNECE R155/CSMS, R156/SUMS, IATF, TISAX, ASPICE, OEM X) demand heavily OVERLAPPING caps.
|
||||
|
||||
Three new measurements the user asked for:
|
||||
- Capability Convergence : per capability, how many sources / how many distinct source TYPES feed it.
|
||||
- Existing-vs-New : how many required caps reuse the EXISTING registry vs are genuinely new
|
||||
(a registry-convergence signal — high reuse => the core is forming).
|
||||
- Business Leverage : the most convergent cap satisfies N regulations AND unlocks a market — more
|
||||
convincing to a GF than "satisfies five laws".
|
||||
|
||||
Data only (a YAML + injected Required caps), zero runtime code. Synthetic, no real names. No deploy.
|
||||
Run: cd backend-compliance && PYTHONPATH=. python3 reference_scenarios/automotive_convergence_stress_test.py
|
||||
"""
|
||||
from __future__ import annotations
|
||||
|
||||
import os
|
||||
import yaml
|
||||
|
||||
from compliance.company import (
|
||||
CompanyContext, Certification, CapabilityMappingEntry, build_company_profile,
|
||||
)
|
||||
from compliance.reasoning.enums import Confidence
|
||||
from compliance.transition_reasoning import (
|
||||
TransitionContext, TransitionGoal, TargetRequirement, assess_transition, CoverageStatus,
|
||||
)
|
||||
|
||||
OUT = []
|
||||
|
||||
|
||||
def w(s=""):
|
||||
OUT.append(s)
|
||||
|
||||
|
||||
_HERE = os.path.dirname(__file__)
|
||||
A = yaml.safe_load(open(os.path.join(_HERE, "..", "knowledge", "domains", "automotive", "source_capabilities.yaml"), encoding="utf-8"))
|
||||
SOURCES = A["sources"]
|
||||
|
||||
# ── known capability universe = caps already modelled in the cyber + environmental patterns ──
|
||||
_K = os.path.join(_HERE, "..", "knowledge", "transition_patterns")
|
||||
known = set()
|
||||
for f in os.listdir(_K):
|
||||
if f.endswith(".yaml"):
|
||||
p = yaml.safe_load(open(os.path.join(_K, f), encoding="utf-8"))
|
||||
known |= {a["capability"] for a in p.get("likely_covered", [])}
|
||||
known |= {d["capability"] for d in p.get("delta_requirements", [])}
|
||||
|
||||
# ── one multi-certified company profile (many overlapping sources) ──────────────────────────
|
||||
prof_caps = A["company_profile_capabilities"]
|
||||
cmap = {k: CapabilityMappingEntry(capability_ids=v, confidence=Confidence.MEDIUM) for k, v in prof_caps.items()}
|
||||
profile = build_company_profile(
|
||||
CompanyContext(company_id="auto", certifications=[Certification(certification_id=k) for k in prof_caps]), cmap)
|
||||
|
||||
# ── required = union of all source caps for "ECU for OEM X"; delta via the SAME engine ───────
|
||||
required = sorted({c for s in SOURCES for c in s["requires"]})
|
||||
assess = assess_transition(TransitionContext(company_id="auto", target=TransitionGoal(target_id="ECU_for_OEM_X")),
|
||||
[TargetRequirement(capability_id=c) for c in required], profile)
|
||||
delta = sorted({c.capability_id for c in assess.coverage if c.status == CoverageStatus.MISSING})
|
||||
|
||||
# ── Capability Convergence: per cap -> sources + distinct source types ───────────────────────
|
||||
conv = {}
|
||||
for cap in required:
|
||||
srcs = [s for s in SOURCES if cap in s["requires"]]
|
||||
conv[cap] = (sorted(s["id"] for s in srcs), sorted({s["type"] for s in srcs}))
|
||||
ranked = sorted(required, key=lambda c: (-len(conv[c][0]), -len(conv[c][1]), c))
|
||||
|
||||
# ── Existing-vs-New (registry convergence signal) ───────────────────────────────────────────
|
||||
reuse = sorted(c for c in required if c in known)
|
||||
fresh = sorted(c for c in required if c not in known)
|
||||
reuse_pct = round(100 * len(reuse) / len(required)) if required else 0
|
||||
|
||||
w("# Automotive Convergence Stress Test — überlebt EINE Capability viele Quellen? (Phase Ω #2)")
|
||||
w("")
|
||||
w('_Nicht noch eine Domäne, sondern eine andere Eigenschaft: bleibt das Modell stabil, wenn dieselbe Capability gleichzeitig aus vielen überlappenden Quellen gespeist wird? Realistisch: ein Zulieferer (ISO 9001 + IATF 16949 + TISAX + ASPICE + CSMS + SUMS) entwickelt ein Steuergerät für OEM X. Sieben Quellen, bewusste Überlappung. Data-only, keine echten Namen._')
|
||||
w("")
|
||||
w("## 1. Sieben überlappende Quellen, eine Engine")
|
||||
w("- Quellen: %s." % ", ".join("`%s`(%s)" % (s["id"], s["type"]) for s in SOURCES))
|
||||
w('- **%d distinct geforderte Capabilities** für „Steuergerät → OEM X" — über dieselbe `assess_transition`-Engine, 0 neue Runtime-Klassen.' % len(required))
|
||||
w("- Delta (fehlt dem Profil): **%d** Capabilities." % len(delta))
|
||||
w("")
|
||||
|
||||
# ── 2. Capability Convergence ──────────────────────────────────────────────
|
||||
w("## 2. Capability Convergence — dieselbe Capability aus vielen Quellen")
|
||||
w("| Capability | Sources | Distinct Source Types | aus |")
|
||||
w("|---|---:|---:|---|")
|
||||
for cap in ranked[:8]:
|
||||
srcs, types = conv[cap]
|
||||
w("| `%s` | %d | %d | %s |" % (cap, len(srcs), len(types), ", ".join(srcs)))
|
||||
w("")
|
||||
top = ranked[0]
|
||||
w('→ **`%s`** ist am konvergentesten: **%d Quellen** über **%d Quelltypen** — eine Maßnahme, viele Nachweiswelten. Genau hier entsteht der wirtschaftliche Nutzen (nicht „300 Gesetze", sondern „eine Capability ersetzt fünf Nachweiswelten").' % (top, len(conv[top][0]), len(conv[top][1])))
|
||||
w("")
|
||||
|
||||
# ── 3. Existing-vs-New (registry convergence) ──────────────────────────────
|
||||
w("## 3. Existing-vs-New — beginnt die Registry zu konvergieren?")
|
||||
w("- **Bereits vorhandene MCAPs (Reuse aus Cyber/Umwelt): %d/%d = %d%%** — z. B. %s." % (
|
||||
len(reuse), len(required), reuse_pct, ", ".join("`%s`" % c for c in reuse[:5]) + " …"))
|
||||
w("- **Genuin neu (Automotive-spezifisch): %d** — z. B. %s." % (
|
||||
len(fresh), ", ".join("`%s`" % c for c in fresh[:5]) + " …"))
|
||||
w("- **Lesart:** %s" % (
|
||||
"Hohe Wiederverwendung → die Registry konvergiert, ein Kern bildet sich." if reuse_pct >= 60 else
|
||||
"Spürbare Wiederverwendung (%d%%) — der Kern beginnt sich zu bilden; der automotive-spezifische Rest (CSMS/SUMS/ASPICE/Funktionssicherheit) ist erwartbar neu. Kein Architekturbruch, sondern ein Hinweis auf den Reifegrad der Capability-Zerlegung." % reuse_pct))
|
||||
w("")
|
||||
|
||||
# ── 4. Business Leverage ───────────────────────────────────────────────────
|
||||
top_srcs, top_types = conv[top]
|
||||
regs = [s for s in top_srcs if next(x["type"] for x in SOURCES if x["id"] == s) == "regulation"]
|
||||
contracts = [s for s in top_srcs if next(x["type"] for x in SOURCES if x["id"] == s) == "contract"]
|
||||
w('## 4. Business Leverage — Märkte + Regulierung, nicht nur „Gesetze"')
|
||||
w("- `%s` erfüllt gleichzeitig **%d Regelwerke** (%s) **und** öffnet den **OEM-Markt** (%s)." % (
|
||||
top, len(regs), ", ".join(regs), ", ".join(contracts) or "—"))
|
||||
w('- Managementsatz: **„Diese eine Capability erfüllt %d regulatorische Anforderungen UND ist Eintrittskarte zum OEM-Geschäft"** — überzeugender als „erfüllt %d Gesetze". (Regulatory Leverage zählt Regelwerke; **Business Leverage** zählt Regelwerke + erschlossene Märkte/Kunden.)' % (len(regs), len(regs)))
|
||||
w("")
|
||||
|
||||
# ── Befund ─────────────────────────────────────────────────────────────────
|
||||
w("## Befund")
|
||||
w("")
|
||||
w('> **Eine Capability aus bis zu %d Quellen über %d Quelltypen — das Modell blieb stabil (0 neue Runtime-Klassen, 0 neue Pipeline; reine Daten).** Convergence ist messbar geworden, und %d%% der Automotive-Anforderungen bilden auf BESTEHENDE MCAPs ab — die Registry beginnt zu konvergieren. Nächster Schritt ist bewusst KEINE neue Domäne, sondern **innehalten und die Registry analysieren**: welche MCAPs tauchen domänenübergreifend (CRA·MaschinenVO·OEM·TISAX·ASPICE·Umwelt) am häufigsten auf? Diese hochkonvergenten Capabilities sind der dauerhaft wertvollste Plattformkern.' % (
|
||||
len(conv[top][0]), len(conv[top][1]), reuse_pct))
|
||||
w("")
|
||||
|
||||
print("\n".join(OUT))
|
||||
@@ -0,0 +1,62 @@
|
||||
"""Automotive convergence stress test — the SAME capability from many sources (Phase Ω #2).
|
||||
|
||||
Pins the convergence property: a realistic multi-certified supplier (ISO 9001 + IATF 16949 + TISAX +
|
||||
ASPICE + CSMS + SUMS) developing an ECU for OEM X feeds the SAME capability from many overlapping
|
||||
Requirement Sources, and the model stays stable (0 runtime). Checks the three new measurements:
|
||||
Capability Convergence (sources x distinct types), Existing-vs-New reuse, and Business Leverage.
|
||||
"""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
import os
|
||||
import subprocess
|
||||
import sys
|
||||
|
||||
|
||||
def _run():
|
||||
root = os.path.join(os.path.dirname(__file__), "..")
|
||||
r = subprocess.run(
|
||||
[sys.executable, "reference_scenarios/automotive_convergence_stress_test.py"],
|
||||
cwd=root, env={**os.environ, "PYTHONPATH": "."}, capture_output=True, text=True,
|
||||
)
|
||||
assert r.returncode == 0, r.stderr
|
||||
return r.stdout
|
||||
|
||||
|
||||
def test_runs_end_to_end_multi_source():
|
||||
out = _run()
|
||||
assert "Automotive Convergence Stress Test" in out
|
||||
assert "27 distinct geforderte Capabilities" in out
|
||||
assert "0 neue Runtime-Klassen" in out
|
||||
|
||||
|
||||
def test_capability_convergence_ranks_the_most_shared_cap_first():
|
||||
out = _run()
|
||||
# the most convergent capability is fed by 4 sources across 3 distinct source types
|
||||
assert "| `technical_vulnerability_management` | 4 | 3 |" in out
|
||||
assert "| `secure_signed_update_distribution` | 4 | 2 |" in out
|
||||
|
||||
|
||||
def test_existing_vs_new_reuse_signal():
|
||||
out = _run()
|
||||
# 13 of 27 required caps reuse existing cyber/environmental MCAPs (registry converging)
|
||||
assert "Reuse aus Cyber/Umwelt): 13/27 = 48%" in out
|
||||
assert "Registry zu konvergieren" in out
|
||||
|
||||
|
||||
def test_business_leverage_is_markets_plus_regulation():
|
||||
out = _run()
|
||||
assert "Business Leverage" in out
|
||||
assert "öffnet den **OEM-Markt**" in out
|
||||
|
||||
|
||||
def test_recommends_registry_analysis_not_next_domain():
|
||||
out = _run()
|
||||
assert "innehalten und die Registry analysieren" in out
|
||||
assert "Plattformkern" in out
|
||||
|
||||
|
||||
def test_no_real_company_names():
|
||||
out = _run().lower()
|
||||
for name in ["eto", "owis", "winterhalter", "bmw", "volkswagen", "bosch"]:
|
||||
assert name not in out
|
||||
Reference in New Issue
Block a user