ThreatZ für Lkw-, Bus- undOff-Highway-Cybersecurity
ThreatZ führt das Cybersecurity-Engineering eines Nutzfahrzeugprogramms genauso wie das eines Pkw-Programms: ein Programm mit vielen Varianten und Märkten, ein Projekt je ECU oder System, TARA, SBOM- und CVE-Abgleich, Incident-Steuerung, ein Lieferanten-Arbeitsbereich und Arbeitsprodukte nach ISO/SAE 21434. Die Plattform ist fahrzeugklassenunabhängig. Was sie nicht tut: entscheiden, welche Regulierung für Ihre Kategorie in Ihrem Markt gilt. Sonderfahrzeuge und Off-Highway-Fahrzeuge können außerhalb des Geltungsbereichs der UN R155 liegen, eine Abdeckung wird nicht impliziert, und der Geltungsbereich je Kategorie wird je Markt bestätigt, bevor sich jemand darauf verlässt.
1 · FAHRZEUGKLASSEN
Fahrzeugklassen und regulatorischer Geltungsbereich
Die Plattform ändert sich nicht mit der Klasse; die Pflichten tun es. Die folgende Tabelle ist die Fahrzeugklassen-Matrix, wie sie für diese Website freigegeben wurde, einschließlich aller Vorbehalte. Wo eine Zelle „noch zu bestätigen“ sagt, ist das der Stand der Aussage, kein Platzhalter: Er wird mit Ihrer Homologations- oder Typgenehmigungsleitung je Markt bestätigt, bevor sich jemand darauf verlässt.
| Klasse | Typische Einordnung | Was es für das Programm bedeutet |
|---|---|---|
| M1 Pkw | Höchstes Volumen, kürzester Zyklus | UN R155 / R156 im Geltungsbereich; größte Varianten- und Marktverzweigung. Hier als Referenzzeile aufgeführt, mit der die Nutzfahrzeugklassen verglichen werden — bestätigen Sie, dass kein Zielmarkt M1 ausnimmt. |
| M2 / M3 Busse und Reisebusse | Personenbeförderung, flottenbetrieben | Gleicher regulatorischer Rahmen wie M1 — Anwendbarkeit auf die Kategorie und Zeitpläne je Markt noch zu bestätigen. Der Betreiber ist ein Dritter, der Fragen stellt; der Verfügbarkeitsdruck ist seiner und Ihrer. |
| N1–N3 Lkw, leicht bis schwer | Lange Nutzungsdauer, flottenbetrieben | Längere Supportpflicht — Kategoriedetails noch zu bestätigen; Exposition durch Telematik und Ferndiagnose; Stillstand verursacht direkte Umsatzkosten. |
| O Anhänger | Routinemäßig vergessen | Berücksichtigt, wo mindestens eine ECU verbaut ist — Gewichtsklasse und Markt noch zu bestätigen. Leicht zu unterdeklarieren. |
| Sonderfahrzeuge / Off-Highway | Sonderaufbauten, geringe Stückzahl | Können außerhalb des Geltungsbereichs der R155 liegen. Eine Abdeckung wird nicht impliziert; Kategorie und Markt werden bestätigt, bevor man sich darauf verlässt. |
Der Geltungsbereich je Kategorie wird je Markt bestätigt, bevor man sich darauf verlässt. Nichts in dieser Tabelle behauptet eine Gleichstellung der Klassen, knüpft eine Pflicht aus dem EU CRA an ein typgenehmigtes Fahrzeug oder sagt, wessen Pflicht ein in mehreren Stufen fertiggestelltes Fahrzeug ist — das sind Fragen, die diese Seite in den folgenden Abschnitten stellt, nicht Antworten, die sie gibt. Vollständige Matrix und Freigabehinweise: Fahrzeugklassen auf der Seite für Systemlieferanten.
2 · WORKFLOWS
Workflows, die für Nutzfahrzeugprogramme gelten
Sechs Stellen, an denen ein Lkw-, Bus- oder Anhängerprogramm die Plattform stärker beansprucht als ein Pkw-Programm. Jede beschreibt, was ThreatZ heute tut, wie auf den Seiten OEM, Tier-1, Modellierung, Lieferkette und Incident Response dokumentiert. Wo die regulatorische Antwort offen ist, ist sie als Frage formuliert.
Ein Programm, viele Varianten und Märkte
Ein Programm bündelt die Security-Projekte, aus denen ein Fahrzeugprogramm besteht; ein Projekt ist der Analyseumfang einer ECU oder eines Systems, als Grenze auf der Architektur der Programmebene gezeichnet. Varianten und Kundenprogramme sind Abzweigungen einer Baseline: neu binden, nur analysieren, was abweicht. Die Typgenehmigung wird für eine bestimmte Konfiguration erteilt, und Baselines machen „was genau genehmigt wurde“ zu einem abrufbaren Zustand — mit einem Vier-Augen-Gate auf der Genehmigung selbst.
Lange Nutzungsdauer und das Supportfenster
Ein Fahrzeug der N-Kategorie bleibt länger im Einsatz als ein Pkw, und die freigegebene Matrix verzeichnet eine längere Supportpflicht — Kategoriedetails noch zu bestätigen. Wie lange dieses Fenster läuft und nach welchem Instrument, ist eine Frage, die wir je Markt stellen: Ist es eine Software-Update-Pflicht nach UN R156, und knüpft überhaupt ein Supportzeitraum aus dem EU CRA an das typgenehmigte Fahrzeug an — oder nur an separat in Verkehr gebrachte digitale Produkte wie eine Telematikeinheit? Diese Seite beantwortet das nicht. Was die Plattform tut: Sie hält die SBOM je Softwareeinheit versioniert je Baseline, vergleicht jeden Re-Import mit der letzten Lieferung und gleicht Komponenten mit Schwachstellen-Feeds ab, solange das Programm offen gehalten wird.
Mehrstufige Fertigung und Aufbauhersteller
Ein Lkw- oder Bus-Fahrgestell wird häufig von einem Aufbauhersteller oder einem Hersteller der zweiten Stufe fertiggestellt. Der Cybersecurity-Nachweis für ein Teilsystem wird daher durch zwei Hersteller gereicht, bevor eine Behörde ihn liest — und wer die Pflicht für das fertiggestellte Fahrzeug trägt, ist eine offene Frage, die wir stellen, nicht eine, die die Plattform klärt. Was ThreatZ diesem Leser bietet, ist eine Aufzeichnung, die dafür gebaut ist, kalt gelesen zu werden, von einer Partei, die nie im Raum war: ein benannter Anker, Urheberschaft je Zeile, eine Historie, die nur ergänzt und nie überschrieben wird, und ein deklariertes Ende, gerendert je Zielgruppen-Voreinstellung.
Telematik und Ferndiagnose als Exposition in der TARA
Flottenbetriebene Fahrzeuge tragen standardmäßig Telematik- und Ferndiagnoseschnittstellen, und die Matrix führt diese Exposition bei den N-Kategorien auf. In ThreatZ ist die Telematik-Steuereinheit ein Projekt wie jede andere ECU: Ihre Schnittstellen und Signale werden zu TARA-Assets, die Angriffspfadanalyse bewertet die Pfade, die sie erreichen, und die Machbarkeit kann über dieselben Pfade nach Angriffspotenzial, CVSS oder Angriffsvektor bewertet werden. Nichts auf dieser Seite behauptet eine Verbindung zu einem Telematik-Backend oder eine Übernahme von Flottentelemetrie: Die Exposition wird hier analysiert, nicht betrieben.
Lieferantennachweise über OEM-Programme hinweg
Ein Tier-1, der dieselbe ECU-Familie an mehrere Nutzfahrzeug-OEMs liefert, modelliert sie einmal als Security Blueprint und klont sie je Kundenprogramm, wobei das Delta analysiert wird. Auf OEM-Seite arbeiten Lieferanten innerhalb des OEM-Prozesses: Ein Advisory versendet einen untergeordneten Incident an das betroffene Projekt, der die Weisung und die deklarierten Kriterien des OEM trägt, der Lieferant bearbeitet ihn in seinem eigenen Projekt, und das Programm ist das einzige Gate nach außen. RBAC auf Entitätsebene hält die Arbeit eines Kunden für einen anderen im selben Mandanten unsichtbar.
Fleet Map: von der Teilenummer zu zugelassenen Fahrzeugen je Markt
Ein Lieferant deklariert die ECU-Teilenummern, die er liefert, gegen eine Projekt-Baseline; ThreatZ gleicht sie mit den Teilenummern ab, die das Programm je VIN hält. Ein Befund hat dann einen Nachverfolgungspfad — Softwarekomponente → Softwareeinheit → Systemkomponente → Teilenummer — und von dort zu den in jedem Markt eingesetzten Fahrzeugen. Die Fleet & Risk Map zeigt Fahrzeuge, aktive CVEs und ein Risikoband je Markt (US, DE, CN, JP, BR, AE; alles andere unter „Other“ gruppiert); die Traceability Map bohrt einen Markt bis zu seinen betroffenen VINs herunter. Beide sind Ansichten des Enterprise-Tiers.
3 · DURCHGERECHNETES BEISPIEL
Ein durchgerechnetes Beispiel: ein Schwer-Lkw-Programm, eine Telematik-ECU, ein Advisory
Illustrativ — kein KundeDie folgenden Zahlen sind erfunden, um die Form der Kette zu zeigen. Es sind keine Kundendaten, und die Marktfristen bleiben absichtlich als „je bestätigtem Instrument“ stehen: Welche Regulierung für ein N3-Fahrzeug in einem bestimmten Markt gilt und nach welchem Zeitplan, bestätigt die Homologationsleitung; dieses Beispiel setzt es nicht voraus.
| Schritt | Was auf der Plattform geschieht | Beispielwert (illustrativ) |
|---|---|---|
| 1 · Programm | Ein N3-Schwer-Lkw-Programm. Jede ECU oder jedes System ist ein Projekt; die Telematik-Steuereinheit (TCU) ist eines davon, geliefert von einem Tier-1, der in einem föderierten Projekt arbeitet. | 6 Varianten (3 Fahrerhäuser × 2 Antriebe), 11 ECU-Projekte, zugelassene Flotte in 2 abgebildeten Märkten (DE, BR) |
| 2 · Teilenummern | Der Tier-1 lädt die TCU-Teilenummern gegen seine Baseline hoch. ThreatZ gleicht sie exakt und ohne Beachtung der Groß-/Kleinschreibung mit den Teilenummern des Programms je VIN ab. | 2 Revisionen: TCU Rev. B 9.800 VINs zugeordnet, Rev. C 5.700 VINs |
| 3 · Advisory trifft ein | Eine CVE wird für eine TLS-Bibliothek veröffentlicht. Der deterministische SBOM-Join findet sie nur in der Softwareeinheit von Rev. B; der exakte Join wird nicht gedehnt, um auf Rev. C zu passen. Ein benannter Ingenieur bestätigt den Anker, und die Bestätigung wird mit Wer und Wann aufgezeichnet. | 1 CVE, 1 Softwareeinheit, nur Rev. B |
| 4 · Betroffene Varianten und Märkte | Vom bestätigten Anker läuft die Kette Softwareeinheit → Systemkomponente → Teilenummer → VINs je Markt. Die Fleet & Risk Map hebt die beiden Märkte hervor; die Traceability Map listet die VINs. | 4 von 6 Varianten; 9.800 Fahrzeuge: 7.900 in DE, 1.900 in BR |
| 5 · Fristen | Fristen werden je Regulierung, je Markt, aus der zugelassenen Flotte scharfgeschaltet — wo ein Instrument für diese Kategorie in diesem Markt gilt. Ein Markt ohne Meldeinstrument wird als solcher aufgezeichnet, was ein anderer Sachverhalt ist als „nicht anwendbar“. | Je bestätigtem Instrument je Markt — hier nicht vorausgesetzt |
| 6 · Schweregrad | Berechnet aus der verankerten Verknüpfung über vier Auswirkungsachsen. Wo die erreichbare Menge keine davon bewertet, hält die Aufzeichnung fest, dass der Schweregrad nicht berechnet wurde, und benennt, was fehlte. | Berechnet für Rev. B; keine Schätzung für Rev. C eingetragen |
| 7 · Behebung | Ein untergeordneter Incident wird an das Projekt des Tier-1 versendet und trägt die Weisung und die Kriterien des Programms. Die Behebung wird durch eine erneut importierte Stückliste nachgewiesen, die zeigt, dass die Bibliothek auf eine Version gewechselt ist, die den Befund ausräumt; Nachweise werden fail-closed validiert, bevor sie gespeichert werden. | 1 untergeordneter Incident; 1 CycloneDX-Re-Import; 1 Komponente geändert |
| 8 · Ende | Der Incident schließt in eines von vier vorab deklarierten Enden — behoben, mitigiert, zurückgestellt, nicht anwendbar. Berichte werden je Zielgruppen-Voreinstellung gerendert, einschließlich eines Behördenpakets, aus derselben nur ergänzten Aufzeichnung. | Ende: behoben; 2 Berichtsvorlagen gerendert |
Jeder Mechanismus in dieser Tabelle ist auf der Incident-Response-Seite und der Lieferketten-Seite beschrieben; nur die Zahlen sind erfunden. Das Beispiel sagt nicht, ob die DE- oder BR-Flotte für N3 unter ein bestimmtes Instrument fällt — das ist die Frage, die Schritt 5 der Homologationsleitung überlässt.
4 · GRENZEN DES GELTUNGSBEREICHS
Grenzen des Geltungsbereichs
Lesen Sie diese vor dem Produktrundgang. Es sind die Aussagen, die diese Seite absichtlich nicht trifft.
- Off-Highway- und Sonderfahrzeuge können außerhalb des Geltungsbereichs der UN R155 liegen. Eine Abdeckung wird nicht impliziert. Welche Typen ausgenommen sind, in welchen Märkten, und ob eine Aufteilung in Fahrgestell plus Sonderaufbau Teilpflichten beim Fahrgestellhersteller belässt, wird je Markt bestätigt, bevor man sich darauf verlässt.
- Es werden keine Lkw-spezifischen Protokollpakete beansprucht. Diese Seite beansprucht keine J1939-, ISOBUS- oder andere Schwerfahrzeug-Protokollbibliothek und keine Telematik- oder Flottenmanagement-Integration. Das Systemmodell wird aus den auf der Modellierungsseite aufgeführten Importen aufgebaut oder auf dem Canvas gezeichnet.
- Standards für Land- und Baumaschinen werden nicht adressiert. ThreatZ ordnet seine Arbeitsprodukte ISO/SAE 21434, UN R155/R156, GB 44495 und, wo das Instrument gilt, den Meldefristen nach Art. 14 EU CRA zu. Eine Zuordnung zu Standards für Land- oder Off-Highway-Maschinen wird nicht beansprucht.
- Zeitpläne je Kategorie werden je Markt bestätigt. Anwendbarkeit und Zeitpläne für M2/M3, Kategoriedetails für N1–N3 und die Gewichtsklassen-Untergrenze für O-Anhänger sind in der freigegebenen Matrix alle als „noch zu bestätigen“ ausgewiesen, und diese Seite belässt sie dabei. Hier wird keine Pflicht aus dem EU CRA an das typgenehmigte Fahrzeug geknüpft.
- Beziehungen zu Typgenehmigungsbehörden liegen außerhalb des Geltungsbereichs. ThreatZ erzeugt die Aufzeichnung, aus der der Nachweis eines Herstellers schöpft. Sie ist keine Zertifizierung, sie reicht nichts bei einer Behörde ein, und sie sagt nicht, welcher Hersteller in einer mehrstufigen Fertigung die Pflicht für das fertiggestellte Fahrzeug trägt.
5 · FAQ
Häufig gestellte Fragen
Deckt ThreatZ Lkw, Busse und Anhänger unter UN R155 ab?
ThreatZ ist fahrzeugklassenunabhängig: Die Programm-, Projekt-, TARA-, SBOM- und Incident-Workflows laufen für einen N3-Lkw genauso wie für einen M1-Pkw. Ob UN R155 oder R156 für Ihre Kategorie in Ihrem Markt gilt und nach welchem Zeitplan, bestätigt Ihre Homologationsleitung je Markt. Die Plattform entscheidet nicht über die Anwendbarkeit, und diese Seite behauptet sie nicht.
Sind Off-Highway- oder Landmaschinen im Geltungsbereich?
Sonderfahrzeuge und Off-Highway-Fahrzeuge können außerhalb des Geltungsbereichs der UN R155 liegen, und eine Abdeckung wird nicht impliziert. Sie können die Maschine dennoch modellieren, eine TARA durchführen und ihre SBOM als Engineering-Übung nachverfolgen, aber ThreatZ ordnet diese Arbeit keinen Standards für Land- oder Off-Highway-Maschinen zu, und diese Seite beansprucht keine solche Zuordnung. Kategorie und Markt werden bestätigt, bevor man sich darauf verlässt.
Liefert ThreatZ eine J1939- oder ISOBUS-Protokollbibliothek?
Eine solche Bibliothek wird nicht beansprucht. Das Systemmodell wird aus den auf der Modellierungsseite aufgeführten Importen aufgebaut, etwa ARXML, System Composer, EA XMI, ODX/PDX/CDD und DBC, oder auf dem Canvas gezeichnet. Busse, Schnittstellen und Signale aus diesen Quellen werden zu TARA-Assets. Protokollspezifische Pakete für Lkw oder Landmaschinen sind nicht Teil dessen, was diese Seite beschreibt.
Wer trägt die Pflicht, wenn ein Aufbauhersteller das Fahrgestell fertigstellt?
Das ist eine Frage, die wir stellen, nicht eine, die die Plattform beantwortet. Ein Lkw- oder Bus-Fahrgestell wird häufig von einem Hersteller der zweiten Stufe fertiggestellt, sodass Nachweise durch zwei Hersteller gehen, bevor eine Behörde sie liest. Was ThreatZ bereitstellt, ist eine Aufzeichnung, die eine Partei, die Ihre Plattform nie geöffnet hat, kalt lesen kann: ein benannter Anker, Urheberschaft je Zeile und ein deklariertes Ende.
Wie erreicht die Fleet Map ein zugelassenes Fahrzeug?
Ein Lieferant lädt ECU-Teilenummern gegen eine Projekt-Baseline hoch, und ThreatZ gleicht sie exakt und ohne Beachtung der Groß-/Kleinschreibung mit den Teilenummern ab, die das Programm je VIN hält. Ein Befund lässt sich dann von der Softwarekomponente über die Softwareeinheit und die Systemkomponente zur Teilenummer nachverfolgen und weiter zu den Fahrzeugen in jedem Markt. Die Fleet and Risk Map ist eine Ansicht des Enterprise-Tiers.
Bringen Sie ein Lkw- oder Busprogramm mit.
Wir führen die Kette auf Ihrer Struktur durch.
Bringen Sie die Variantenzahl, die Märkte, in denen Sie zulassen, und eine ECU mit, die Ihnen Sorgen macht. Wir gehen vom Advisory bis zur zugelassenen Flotte auf einem laufenden Build — und lassen die Fragen zur regulatorischen Anwendbarkeit dort, wo sie hingehören: bei Ihrer Homologationsleitung.