Dieser Post baut auf der EthTrcv-Serie auf und knüpft an den vorherigen Post zu gPTP an. Dort ging es um Zeitsynchronisation über Ethernet — hier geht es um die Frage, die jeder Safety-Ingenieur früher oder später stellt: Was passiert, wenn der PHY einen Fehler nicht meldet, obwohl einer vorliegt?
Ethernet war ursprünglich ein Best-Effort-Medium für IT-Netzwerke. Im Fahrzeug trägt es heute Frames für ADAS-Sensorfusion, Bremsanforderungen und Lenkwinkelvorgaben. Diese Verschiebung — von "Daten kommen meistens an" zu "Daten müssen ankommen, oder das System muss es merken" — ist der Kern dieses Posts.
Warum Functional Safety für EthTrcv überhaupt relevant wird
Solange Ethernet nur Diagnose- oder Infotainment-Daten transportiert hat, war ein PHY-Ausfall ein Komfortproblem. Das hat sich geändert.
Zonal Architecture — Ethernet als Backbone
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Sensor-ECU │ 1000 │ Zonal │ 1000 │ Domain │
│ (Radar/Kamera)├─BASE-T1─► Controller ├─BASE-T1─► Controller │
└──────────────┘ └──────┬───────┘ │ (ADAS/Brems-│
│ │ steuerung) │
EthTrcv + PHY └──────────────┘
auf jedem LinkWenn zwischen Radar-ECU und Domain-Controller nur noch Ethernet liegt — kein redundanter CAN-Pfad mehr für die sicherheitsrelevante Botschaft — dann ist der EthTrcv-Link Teil der Sicherheitskette. Ein stiller Fehler auf diesem Link (Frame kommt korrupt an, aber der Link-Status meldet weiterhin "up") ist potenziell gefährlicher als ein kompletter Link-Ausfall, weil ihn niemand bemerkt.
Der PHY selbst ist in der Regel kein ASIL-D-Baustein. Die eigentliche Sicherheitsfunktion (z. B. "Bremsanforderung mit Timeout X erkennen") wird meist auf einer höheren Softwareschicht realisiert (E2E-Schutz, Plausibilisierung). Der PHY liefert dafür aber notwendige Diagnoseinformationen — und muss dafür seinerseits "safety-related" qualifiziert sein. |
ISO 26262 & AUTOSAR — ASIL-Dekomposition im Ethernet-Stack
ISO 26262 verlangt keine durchgängige ASIL-D-Qualifikation jeder einzelnen Komponente. Stattdessen wird über ASIL-Dekomposition (ISO 26262-9) die Verantwortung auf mehrere unabhängige Elemente verteilt, sodass jedes Element einen geringeren ASIL-Anteil trägt — vorausgesetzt, die Elemente sind ausreichend unabhängig voneinander (Freedom from Interference).
Beispiel: ASIL-D-Sicherheitsziel "Bremsanforderung erkennen"
dekomponiert über zwei unabhängige Pfade
ASIL D = ASIL B(D) + ASIL B(D)
│ │
Ethernet-Pfad Redundanter Pfad
(EthTrcv, E2E) (z. B. zweiter Sensor,
anderes Medium/Timing)In der Praxis sieht die Aufteilung im EthTrcv-nahen Software-Stack meist so aus:
| Schicht | Trägt bei zu | Typischer ASIL-Anteil |
|---|---|---|
PHY-Hardware (z. B. TJA1101) | Fehlererkennung auf Leitungsebene, Diagnoseregister | Meist QM mit "Safety Element out of Context" (SEooC) Nachweis, teils bis ASIL B |
EthTrcv (BSW-Treiber) | Weiterleitung von Link-/Fehlerstatus an höhere Schichten, keine eigene Fehlerkorrektur | QM bis ASIL B, abhängig vom Decomposition-Konzept |
Eth (MAC-Treiber) / EthIf | Transparente Weiterleitung, Statistikzähler | QM bis ASIL B |
E2E-Bibliothek (oberhalb von PduR/Com) | Erkennung von Verlust, Vertauschung, Korruption auf Nachrichtenebene | Trägt üblicherweise den größten ASIL-Anteil (bis ASIL D via Decomposition) |
Anwendungssoftware (SWC) | Plausibilisierung, Timeout-Überwachung, Freigabelogik | ASIL des Sicherheitsziels |
Ein häufiges Missverständnis: "EthTrcv ist ASIL-B qualifiziert" bedeutet in der Regel nicht, dass der Treiber selbst eine Sicherheitsfunktion ausführt. Es bedeutet meist, dass der Treiber nach einem entsprechenden Sicherheitslebenszyklus entwickelt wurde (Tool-Qualifikation, Verifikation, Rückverfolgbarkeit) und seine Fehlerfortpflanzung (Freedom from Interference) analysiert und begrenzt ist. |
Die eigentliche Sicherheitsfunktion liegt fast immer oberhalb von EthTrcv — in der E2E-Absicherung und der Anwendungslogik. EthTrcv ist aber die Quelle der Rohdaten, auf denen diese Schichten aufbauen: Ohne zuverlässige Link-Status- und Fehlermeldungen vom PHY kann keine höhere Schicht sinnvoll entscheiden, ob ein Timeout auf einen echten Kommunikationsfehler oder auf einen physikalischen Defekt zurückzuführen ist.
Fehlererkennungsmechanismen im PHY
Der PHY-Chip selbst bringt mehrere Diagnosemechanismen mit, die über MDIO (siehe Hardware Deep Dive) ausgelesen werden können. Diese Mechanismen sind die Basis für alles, was EthTrcv später an die höheren Schichten meldet.
Kabeldiagnose — TDR (Time Domain Reflectometry)
TDR sendet einen definierten Testimpuls auf die Leitung und misst die Reflexion, die durch Impedanzsprünge (Kurzschluss, Unterbrechung, Stecker mit Fehlkontaktierung) entsteht.
PHY sendet Testimpuls ──────────────►
Impedanzsprung (z. B. Kabelbruch)
PHY misst reflektierte Energie ◄───────
Laufzeit der Reflexion → Entfernung zum Fehlerort
Amplitude der Reflexion → Art des Fehlers (offen / Kurzschluss / Teilschaden)| TDR-Befund | Interpretation |
|---|---|
Keine Reflexion, Signal vollständig absorbiert | Kabel intakt, Abschluss korrekt terminiert |
Starke positive Reflexion | Leitungsunterbrechung (offener Stromkreis) — Entfernung aus Laufzeit berechenbar |
Starke negative Reflexion | Kurzschluss zwischen den Adern oder gegen Masse |
Schwache, verteilte Reflexion | Beschädigung der Kabelisolierung, Quetschung, beginnende Korrosion am Steckkontakt |
TDR läuft typischerweise nicht kontinuierlich im Fahrbetrieb, sondern wird beim Hochlauf (Power-On Self-Test) oder auf explizite Diagnoseanforderung ausgelöst, da der Testimpuls den regulären Datenverkehr kurzzeitig stört.
Für die Software-Integration relevant: TDR-Ergebnisse liegen in
herstellerspezifischen PHY-Registern (Clause 45 Vendor-Space) und müssen
über einen herstellerspezifischen Treiberanteil ( |
RMS-Amplitudenüberwachung
Der PHY überwacht kontinuierlich die Effektivspannung (RMS) des empfangenen Signals auf der Leitung. Eine Abweichung vom erwarteten Pegelband deutet auf eine sich anbahnende Signalqualitätsverschlechterung hin — oft bevor ein harter Link-Verlust auftritt.
Erwarteter Pegelbereich (100BASE-T1, differenziell): ±1 V nominal
RMS-Messung über Zeit:
100 % ┤ ██████████████████████▓▓▓▓░░░░
│ Nominalbereich Degradation Link-Verlust
└──────────────────────────────────────────────────► Zeit
↑
Frühwarnung möglich,
bevor Link tatsächlich abbrichtDiese Frühwarnfunktion ist für Functional Safety besonders wertvoll: Sie erlaubt einen graduellen Degradationspfad (z. B. Reduktion der Datenrate, Wechsel auf redundanten Pfad) statt eines abrupten, unvorbereiteten Kommunikationsausfalls.
Interne Loopback-Selbsttests
Der PHY kann intern Sendepfad und Empfangspfad kurzschließen, um seine eigene digitale und teilweise analoge Signalverarbeitung zu prüfen — unabhängig vom angeschlossenen Kabel.
Near-End Loopback (digital):
MAC → TX-Pfad → [intern kurzgeschlossen] → RX-Pfad → MAC
Prüft: PCS/PMA-Logik, Scrambling/Descrambling, Clock-Domain-Crossing
Far-End Loopback (über Leitung, mit Gegenstelle):
ECU A → Kabel → ECU B (Loopback aktiv) → Kabel → ECU A
Prüft: gesamte Übertragungsstrecke inkl. Kabel und Gegenstelle| Loopback-Typ | Prüft | Typischer Auslösezeitpunkt |
|---|---|---|
Near-End (intern) | PHY-interne Digital-/Analoglogik | Power-On Self-Test, periodisch im Hintergrund (Off-Line-Test) |
Far-End (über Kabel) | Gesamte Punkt-zu-Punkt-Verbindung | Werkstatt-Diagnose, selten im Fahrbetrieb (unterbricht Nutzdatenverkehr) |
Loopback-Tests unterbrechen während ihrer Laufzeit die reguläre Datenübertragung. Ein Selbsttest, der während eines aktiven sicherheitsrelevanten Datenstroms ausgelöst wird, kann selbst zur Fehlerursache werden, wenn er nicht mit der Anwendungsschicht koordiniert ist (z. B. über einen definierten Diagnosezustand, in dem sicherheitsrelevante Kommunikation ohnehin ruht). |
Temperatur- und Spannungsüberwachung
Automotive-PHYs integrieren üblicherweise On-Chip-Sensoren für Junction-Temperatur und die verschiedenen Versorgungsspannungen (vergleiche die Spannungsdomänen aus dem Hardware Deep Dive).
Überwachte Größen (Beispielwerte, herstellerabhängig):
Junction-Temperatur Warnschwelle ~125 °C, Shutdown ~150 °C
VDD_Core Toleranzband ±5 % um Nominalspannung
VDD_MDI Toleranzband ±10 % um Nominalspannung
Bei Über-/Unterschreitung:
→ Statusbit im Diagnoseregister gesetzt
→ optional: Interrupt-Pin (falls beschaltet)
→ optional: automatischer Shutdown der Sendestufe (Selbstschutz)Diese Mechanismen schützen primär den Chip selbst, liefern aber wichtige Zusatzinformation für die Fehlerursachenanalyse: Ein Link-Verlust bei gleichzeitig gemeldeter Übertemperatur deutet auf eine thermische Ursache hin und nicht auf einen Kabeldefekt — ein Unterschied, der die Fehlerbehandlung in der Anwendungsschicht sinnvoll beeinflussen kann.
Safety-Mechanismen im AUTOSAR-Stack
Die PHY-seitigen Mechanismen liefern Rohdaten. Die eigentliche Sicherheitsarchitektur entsteht erst durch das Zusammenspiel mit den Mechanismen oberhalb von EthTrcv.
E2E-Schutz auf höheren Schichten
Die AUTOSAR E2E-Bibliothek (End-to-End Protection) sichert einzelne Botschaften unabhängig vom darunterliegenden Kommunikationsmedium ab — sie "vertraut" EthTrcv, Eth und dem Netzwerk nicht, sondern prüft jede empfangene Nachricht selbst.
Sender Empfänger
┌─────────────┐ ┌─────────────┐
│ SWC │ │ SWC │
│ Nutzdaten │ │ Nutzdaten │
├─────────────┤ ├─────────────┤
│ E2E-Wrapper │ + Zähler, CRC, ID │ E2E-Wrapper │ prüft:
├─────────────┤ ├─────────────┤ Zähler fortlaufend?
│ Com / PduR │ │ Com / PduR │ CRC korrekt?
├─────────────┤ ├─────────────┤ Timeout eingehalten?
│ EthIf/EthTrcv│──── Ethernet-Link ──────►│ EthIf/EthTrcv│
└─────────────┘ └─────────────┘E2E erkennt dabei genau die Fehlerklassen, die ein "stiller" PHY-Fehler verursachen kann:
| E2E-Prüfung | Erkennt |
|---|---|
Sequenzzähler | Verlorene oder vertauschte Frames, die EthTrcv als "Link up" meldet, obwohl Daten fehlen |
CRC/Prüfsumme | Bitfehler, die trotz Ethernet-eigener FCS (Frame Check Sequence) unentdeckt durchrutschen |
Timeout-Überwachung | Kompletter Ausfall des Datenstroms bei weiterhin bestehendem Link |
Daten-ID | Adressierungsfehler, Konfigurationsfehler bei Routing über EthSwt |
Die Ethernet-eigene FCS (CRC-32 im Frame-Trailer) verwirft fehlerhafte Frames bereits im MAC — das reduziert die Wahrscheinlichkeit stiller Datenkorruption erheblich, ersetzt aber nicht die E2E-Prüfung. FCS schützt gegen Übertragungsfehler auf dem Medium, nicht gegen Fehler, die erst in Software-Schichten oberhalb des MAC entstehen (z. B. Pufferüberläufe, Adressierungsfehler beim Switching). |
Watchdog-Überwachung
Ergänzend zur inhaltlichen E2E-Prüfung überwacht ein Watchdog-Mechanismus (AUTOSAR WdgM), ob die für sicherheitsrelevante Kommunikation zuständigen Softwareteile — inklusive der EthTrcv-Statusabfrage — überhaupt noch regelmäßig ausgeführt werden.
EthTrcv_GetLinkState() muss zyklisch aufgerufen werden
→ Aufruf wird als "Alive"-Checkpoint an WdgM gemeldet
→ bleibt der Checkpoint aus (z. B. Task blockiert, Deadlock)
→ WdgM löst Reaktion aus (Reset, Safe State)Das schützt gegen eine andere Fehlerklasse als E2E: nicht "die Daten sind falsch", sondern "die Überwachung selbst läuft nicht mehr" — etwa weil die Task, die den Link-Status abfragt, hängt oder verhungert.
DEM-Integration — Fehler-Events mappen
Das Diagnostic Event Manager (DEM) Modul ist die zentrale Sammelstelle für Fehlerereignisse im AUTOSAR-Stack. EthTrcv meldet PHY-seitige Fehler über produzierte Diagnostic Events, die der DEM debounced, priorisiert und ggf. an das Freeze-Frame-Handling weiterreicht.
PHY-Diagnoseregister
│ (MDIO-Read, herstellerspezifisch)
▼
EthTrcv erkennt Fehlerzustand
│
▼
Dem_ReportErrorStatus(EventId, DEM_EVENT_STATUS_FAILED)
│
▼
DEM: Debouncing (Zähler / Zeit) ── noch nicht bestätigt ──► kein Eintrag
│
▼ (Schwelle erreicht)
DEM: Event bestätigt
│
├─► Eintrag im Event Memory (persistiert, UDS-auslesbar)
├─► Freeze Frame (Kontextdaten: Zeitstempel, Betriebszustand)
└─► Callback an SW-C / FiM (Function Inhibition Manager)Standard-EthTrcv-Fehlerereignisse
AUTOSAR definiert für EthTrcv die folgenden produzierten Events. Dabei
ist ETHTRCV_E_ACCESS ("Transceiver access failed") das einzige
standardisierte DEM-Event (Produktions-/Laufzeitfehler) für EthTrcv,
referenziert über den ECUC-Container EthTrcvDemEventParameterRefs;
die übrigen Einträge unten sind Entwicklungsfehler (Det), die über
einen separaten Meldeweg laufen:
| Event / Fehlercode | Bedeutung | Typische Debounce-Strategie |
|---|---|---|
| Fehlgeschlagener Transceiver-/MDIO-Zugriff (PHY antwortet nicht) — das standardisierte DEM-Event für EthTrcv | Zählerbasiert, meist mit sofortiger Eskalation bei Wiederholung |
| Ungültiger Pointer bzw. ungültiger Transceiver-Index bei API-Aufruf (Entwicklungsfehler, kein Laufzeitfehler) | Nicht DEM-relevant — Det-Meldung (Development Error Tracer) |
| API-Aufruf vor Initialisierung | Nicht DEM-relevant — Det-Meldung |
Ein dauerhafter Verlust der physikalischen Verbindung ("PHY down") ist
in AUTOSAR selbst kein standardisierter DEM-Eventname — Projekte, die
das als eigenständiges Diagnoseereignis melden wollen, ergänzen dafür
typischerweise eine herstellerspezifische Erweiterung des Containers
EthTrcvDemEventParameterRefs (der Container ist genau für solche
Erweiterungen vorgesehen), statt sich auf einen Standardbezeichner
dafür zu verlassen.
Nicht jedes AUTOSAR-Fehlerereignis ist ein DEM-Event. Entwicklungsfehler
( |
Vendor Safety Events
Über die Standard-Events hinaus bringen viele Automotive-PHYs zusätzliche, herstellerspezifische Safety-Diagnoseregister mit, die nicht 1:1 in der AUTOSAR-Spezifikation abgebildet sind, aber über die Vendor-API oder einen Callout-Mechanismus in den DEM eingebunden werden müssen.
Beispiele herstellerspezifischer Safety Events (schematisch):
VENDOR_E_TDR_FAULT Kabeldiagnose hat Fehler lokalisiert
VENDOR_E_TEMP_WARNING Temperatur-Warnschwelle überschritten
VENDOR_E_RMS_DEGRADED Signalqualität unterhalb Warnschwelle
VENDOR_E_SELFTEST_FAILED Interner Selbsttest (BIST) fehlgeschlagenBei der Integration eines neuen PHYs lohnt sich früh die Frage: Welche Vendor-Diagnoseregister existieren, und welche davon sind laut Safety Manual des Herstellers sicherheitsrelevant? Diese Liste bestimmt, wie viele zusätzliche DEM-Events über den Standard-EthTrcv-Fehlerkatalog hinaus projektiert werden müssen — ein Punkt, der in Aufwandsschätzungen regelmäßig unterschätzt wird. |
Vendor-Beispiel: NXP TJA1101 (ASIL B)
Als konkretes Beispiel eignet sich der NXP TJA1101, ein weit verbreiteter 100BASE-T1-PHY mit ASIL-B-Qualifikation nach ISO 26262. Die folgenden Angaben sind exemplarisch und ersetzen nicht das aktuelle Datenblatt bzw. Safety Manual des Herstellers.
| Safety-Feature | Beschreibung |
|---|---|
ASIL-B-Qualifikation (SEooC) | Entwickelt als "Safety Element out of Context" nach ISO 26262-10 — der Hersteller liefert Sicherheitsziele und Annahmen, die der Systemintegrator übernehmen und validieren muss |
Cable Diagnostic Toolkit | TDR-basierte Kabeldiagnose, auslesbar über MDIO-Register, erkennt Kurzschluss/Unterbrechung inkl. Entfernungsangabe |
Signal Quality Indicator (SQI) | Kontinuierliche Bewertung der Signalqualität als Kennzahl — Basis für Frühwarnung vor Link-Verlust |
Loopback-Modi | Internal, External und Remote Loopback für Selbsttest und Feld-Diagnose |
Übertemperaturschutz | Warnung und automatische Abschaltung der Sendestufe bei Überschreitung der Temperaturschwelle |
Diagnose-Interrupt | Konfigurierbarer INT-Pin, der bei sicherheitsrelevanten Ereignissen einen Interrupt am SoC auslöst, statt auf Polling angewiesen zu sein |
Vereinfachter Ablauf: TJA1101-Diagnoseauswertung durch EthTrcv
1. EthTrcv_MainFunction() (zyklisch)
│
▼
2. MDIO-Read auf Diagnoseregister (Clause 22 Extended Register / Clause 45)
│
▼
3. Statusbits interpretieren:
- Link Status
- Cable Diagnostic Result
- Temperature Warning
- SQI unterhalb Schwelle?
│
▼
4. Bei Fehlerzustand: Dem_ReportErrorStatus() für gemapptes Event
│
▼
5. Bei kritischem Zustand (z. B. Übertemperatur-Shutdown):
zusätzlich Benachrichtigung an EcuM / Safe-State-Handling"ASIL B" beim TJA1101 bedeutet nicht, dass jede einzelne Funktion des Chips mit ASIL B qualifiziert ist. Es bedeutet, dass der Hersteller im Safety Manual dokumentiert, unter welchen Randbedingungen (Diagnostic Coverage, Fehlerreaktionszeiten, Nutzungsprofil) der Baustein in einem Sicherheitskonzept bis ASIL B eingesetzt werden kann. Die Verantwortung für die korrekte Einbettung liegt beim Systemintegrator. |
Zertifizierungsfragen — was der PHY-Hersteller liefern muss
Wer einen PHY in ein sicherheitsrelevantes Steuergerät integriert, braucht vom Hersteller mehr als ein Datenblatt. ISO 26262-8 (unterstützende Prozesse) und -10 (Guideline) definieren, was für die Verwendung als SEooC bzw. für die Interface-Absicherung nötig ist.
| Dokument / Artefakt | Zweck |
|---|---|
Safety Manual | Beschreibt Sicherheitsziele, Annahmen über den Nutzungskontext (Assumptions of Use), unterstützte ASIL-Stufe und notwendige externe Maßnahmen (z. B. Beschaltung, Software-seitige Auswertung von Diagnoseregistern) |
FMEA (Failure Mode and Effects Analysis) | Systematische Analyse möglicher Fehlerarten des Bausteins, deren Auswirkungen und die vom Baustein selbst bereitgestellte Erkennung (Diagnostic Coverage je Fehlerart) |
FMEDA (FMEA + Diagnostic Coverage) | Quantitative Ergänzung der FMEA — liefert Kennzahlen wie SPFM (Single Point Fault Metric) und LFM (Latent Fault Metric), die für die Sicherheitsnachweisführung auf Systemebene benötigt werden |
Development Interface Agreement (DIA) | Vertragliche/organisatorische Klärung, welche Sicherheitsaktivitäten der Halbleiterhersteller übernimmt und welche beim Tier-1/OEM verbleiben |
Nachweis der Tool-/Prozessqualifikation | Nachweis, dass Entwicklungsprozess und ggf. verwendete Tools den Anforderungen des angestrebten ASIL genügen (ISO 26262-8) |
Errata / Known Issues Liste | Bekannte Silizium-Fehler mit Bewertung, ob und wie sie die Sicherheitsargumentation beeinflussen |
Ein PHY ohne Safety Manual ist für ein ASIL-relevantes Sicherheitsziel nicht ohne Weiteres einsetzbar — selbst wenn er technisch die passenden Diagnosefunktionen mitbringt. Ohne dokumentierte Diagnostic Coverage und Assumptions of Use fehlt die Grundlage, um den Baustein in einer FMEDA auf Systemebene korrekt zu bewerten. Das ist einer der häufigsten Gründe, warum ein sonst geeigneter PHY in einem Safety-Review scheitert. |
Für die Integration in den EthTrcv-Softwarestack bedeutet das konkret:
Welche Fehlerarten deckt der PHY selbst ab (Diagnostic Coverage), und welche müssen durch E2E/Anwendungssoftware zusätzlich abgesichert werden?
Welche Reaktionszeit garantiert der PHY zwischen Fehlereintritt und Diagnosemeldung (Fault Detection Time) — passt das zum geforderten Fault Tolerant Time Interval (FTTI) des Sicherheitsziels?
Welche Register müssen zyklisch gepollt werden, und welche lösen einen Interrupt aus? Das beeinflusst direkt die Implementierung von
EthTrcv_MainFunction.
Zusammenfassung
| Thema | Kernaussage |
|---|---|
Warum Safety für EthTrcv relevant ist | Ethernet trägt zunehmend sicherheitsrelevante Botschaften ohne redundanten Nicht-Ethernet-Pfad — stille PHY-Fehler werden dadurch sicherheitsrelevant |
ASIL-Dekomposition | Die eigentliche Sicherheitsfunktion liegt meist oberhalb von EthTrcv (E2E, Anwendungslogik); EthTrcv liefert die dafür nötigen Rohdaten zuverlässig und mit begrenzter Fehlerfortpflanzung |
PHY-Fehlererkennung | TDR, RMS-Amplitudenüberwachung, Loopback-Selbsttests und Temperatur-/Spannungsüberwachung liefern die Diagnosebasis, meist über herstellerspezifische MDIO-Register |
E2E & Watchdog | E2E prüft Nachrichteninhalt und -reihenfolge unabhängig vom Medium; WdgM prüft, dass die Überwachung selbst noch läuft |
DEM-Integration | Das Standard-Event |
Vendor-Beispiel TJA1101 | ASIL-B-PHY mit Cable Diagnostic Toolkit, SQI und Loopback-Modi — SEooC-Qualifikation setzt korrekte Einbettung durch den Integrator voraus |
Zertifizierung | Safety Manual, FMEA/FMEDA und Assumptions of Use sind Pflichtartefakte — ohne sie ist eine Systembewertung nicht möglich |
Weiter in der EthTrcv-Serie: EthTrcv & MACsec — Automotive Cybersecurity auf Layer 2