Using FMEA for Autonomous Diagnostics, Predictive Maintenance and Cross-Layer Security: A Reference Architecture
When an on-board diagnostic or a predictive-maintenance model is listed as a control in a DFMEA or PFMEA, the main question is whether it really lowers Occurrence (prevention) or only improves Detection. The answer also decides whether the diagnostic itself, and the data path it depends on, needs its own failure and threat analysis. This article ties the 7-step method of the AIAG & VDA FMEA Handbook (1st ed., 2019) and IEC 60812:2018 to ISO 26262:2018 diagnostic coverage, ISO 13374 and ISO 17359:2018 condition-monitoring data flows, and ISO/SAE 21434:2021 TARA, so that each control credited in FMEA Tool can be justified and audited.
Prevention vs. detection, decision criteria
credit a prognostic model as a prevention control (lower O) only if it triggers a maintenance action before the failure mode can occur, and the lead time it provides is longer than the time needed to act on it (prognostic horizon > response time). If it only flags a failure that has already started, rate it under Detection. If the input data can be spoofed, delayed or missing, add the diagnostic as its own Structure element in Step 2 and analyse its failure modes there: stale data, a stuck sensor, model drift, or a manipulated message.
Pre-implementation checklist
before you rate a control, collect the sensor sampling rate and latency, the ISO 13374 processing layer where the decision is made (data acquisition → state detection → health assessment → prognostics), the expected false-alarm and missed-detection behaviour, any ISO 26262 diagnostic-coverage targets, and the cybersecurity goals from your ISO/SAE 21434 TARA. Record each of these as a reusable catalog entry so the same assumptions apply across every DFMEA and PFMEA.
Illustrative analytical scenario (not measured data)
a spindle-bearing failure mode has S=8. A vibration-trend model with an assumed 72 h prognostic horizon and a 24 h maintenance window justifies moving O from 6 to 3. The CAN path that carries its alerts has no authentication, so a separate failure-mode entry ('alert suppressed or forged') stays at D=7 until message authentication is added, for example AUTOSAR SecOC. Recovery plan: if the model's inputs are lost, fall back to fixed-interval inspection and revert to the original O rating. Re-run Action Priority, then export the Excel file as audit evidence.
Technical FAQ: How do I verify in FMEA Tool that a predictive-maintenance or diagnostic control deserves the lower Occurrence or Detection rating I gave it?
Write down the assumptions behind the rating: prognostic horizon versus response time, data latency, the expected false-alarm and missed-detection rates, and the TARA cybersecurity goals that protect the data path. Model the diagnostic as a separate Structure element and analyse its own failure modes, then confirm that Action Priority still makes sense once those failures are included. Validate with field or bench evidence that you actually collected; never use vendor claims as proof. If the evidence is missing, or monitoring degrades in operation, go back to the original rating and to time-based inspection, update the catalog entry, and export a new Excel revision so the change can be traced.
More Technical Articles on fmeatool.com
FMEA para Diagnóstico Autônomo, Manutenção Preditiva e Segurança entre Camadas: Arquitetura de Referência
Quando um diagnóstico embarcado ou um modelo de manutenção preditiva entra como controle em um DFMEA ou PFMEA, a pergunta principal é se ele de fato reduz a Ocorrência (prevenção) ou só melhora a Detecção. A resposta também define se o próprio diagnóstico, e o caminho de dados do qual ele depende, precisam de uma análise própria de falhas e ameaças. Este artigo liga o método de 7 passos do Manual FMEA AIAG & VDA (1ª ed., 2019) e da IEC 60812:2018 à cobertura de diagnóstico da ISO 26262:2018, aos fluxos de monitoramento de condição da ISO 13374 e da ISO 17359:2018 e à TARA da ISO/SAE 21434:2021, para que cada controle creditado no FMEA Tool possa ser justificado e auditado.
Prevenção vs. detecção, critério de decisão
só credite um modelo prognóstico como controle de prevenção (O menor) se ele disparar uma ação de manutenção antes que o modo de falha possa ocorrer e se a antecedência que ele oferece for maior que o tempo necessário para agir (horizonte prognóstico > tempo de resposta). Se ele só aponta uma falha que já começou, avalie-o em Detecção. Se os dados de entrada podem ser falsificados, atrasados ou perdidos, inclua o diagnóstico como elemento próprio da Estrutura no Passo 2 e analise ali os modos de falha dele: dado desatualizado, sensor travado, deriva do modelo ou mensagem manipulada.
Checklist pré-implementação
antes de pontuar um controle, levante a taxa de amostragem e a latência do sensor, a camada de processamento da ISO 13374 onde a decisão é tomada (aquisição de dados → detecção de estado → avaliação de saúde → prognóstico), o comportamento esperado de falsos alarmes e de falhas não detectadas, eventuais metas de cobertura de diagnóstico da ISO 26262 e as metas de cibersegurança da sua TARA ISO/SAE 21434. Registre cada item como entrada reutilizável de catálogo, para que as mesmas premissas valham em todos os DFMEA e PFMEA.
Cenário analítico ilustrativo (não são dados medidos)
um modo de falha de rolamento de spindle tem S=8. Um modelo de tendência de vibração com horizonte prognóstico assumido de 72 h e janela de manutenção de 24 h justifica baixar O de 6 para 3. O caminho CAN que transporta os alertas não tem autenticação, então um modo de falha separado ('alerta suprimido ou forjado') fica em D=7 até que se adicione autenticação de mensagens, por exemplo AUTOSAR SecOC. Plano de recuperação: se as entradas do modelo forem perdidas, voltar à inspeção em intervalo fixo e restaurar a nota O original. Recalcule a Prioridade de Ação e exporte o Excel como evidência de auditoria.
FAQ Técnica: Como verificar no FMEA Tool se um controle preditivo ou de diagnóstico merece a nota menor de Ocorrência ou Detecção que eu dei a ele?
Registre as premissas por trás da nota: horizonte prognóstico versus tempo de resposta, latência dos dados, taxas esperadas de falso alarme e de falha não detectada, e as metas de cibersegurança da TARA que protegem o caminho de dados. Modele o diagnóstico como elemento separado da Estrutura e analise os modos de falha dele, depois confirme que a Prioridade de Ação continua fazendo sentido com essas falhas incluídas. Valide com evidências de campo ou de bancada que você realmente coletou; nunca use alegações de fornecedor como prova. Se faltar evidência, ou se o monitoramento se degradar em operação, volte à nota original e à inspeção por tempo, atualize a entrada do catálogo e exporte uma nova revisão do Excel para que a mudança fique rastreável.
Mais Artigos Técnicos em fmeatool.com
FMEA para Diagnóstico Autónomo, Mantenimiento Predictivo y Seguridad entre Capas: Arquitectura de Referencia
Cuando un diagnóstico embarcado o un modelo de mantenimiento predictivo figura como control en un DFMEA o PFMEA, la pregunta principal es si de verdad reduce la Ocurrencia (prevención) o solo mejora la Detección. La respuesta también define si el propio diagnóstico, y la ruta de datos de la que depende, necesitan su propio análisis de fallos y amenazas. Este artículo vincula el método de 7 pasos del Manual FMEA AIAG & VDA (1.ª ed., 2019) y la IEC 60812:2018 con la cobertura de diagnóstico de ISO 26262:2018, los flujos de monitorización de condición de ISO 13374 e ISO 17359:2018 y la TARA de ISO/SAE 21434:2021, para que cada control acreditado en FMEA Tool pueda justificarse y auditarse.
Prevención vs. detección, criterio de decisión
acredite un modelo pronóstico como control de prevención (O menor) solo si dispara una acción de mantenimiento antes de que pueda ocurrir el modo de fallo y si la antelación que ofrece es mayor que el tiempo necesario para actuar (horizonte pronóstico > tiempo de respuesta). Si solo señala un fallo que ya comenzó, valórelo en Detección. Si los datos de entrada pueden falsificarse, retrasarse o perderse, incluya el diagnóstico como elemento propio de la Estructura en el Paso 2 y analice allí sus modos de fallo: dato obsoleto, sensor bloqueado, deriva del modelo o mensaje manipulado.
Checklist previo a la implementación
antes de puntuar un control, reúna la frecuencia de muestreo y la latencia del sensor, la capa de procesamiento de ISO 13374 donde se toma la decisión (adquisición de datos → detección de estado → evaluación de salud → pronóstico), el comportamiento esperado de falsas alarmas y de fallos no detectados, los posibles objetivos de cobertura de diagnóstico de ISO 26262 y los objetivos de ciberseguridad de su TARA ISO/SAE 21434. Registre cada elemento como entrada reutilizable de catálogo, para que las mismas hipótesis valgan en todos los DFMEA y PFMEA.
Escenario analítico ilustrativo (no son datos medidos)
un modo de fallo de rodamiento de husillo tiene S=8. Un modelo de tendencia de vibración con un horizonte pronóstico supuesto de 72 h y una ventana de mantenimiento de 24 h justifica bajar O de 6 a 3. La ruta CAN que transporta sus alertas no tiene autenticación, así que un modo de fallo aparte ('alerta suprimida o falsificada') se queda en D=7 hasta que se añada autenticación de mensajes, por ejemplo AUTOSAR SecOC. Plan de recuperación: si se pierden las entradas del modelo, volver a la inspección a intervalo fijo y restaurar la O original. Recalcule la Prioridad de Acción y exporte el Excel como evidencia de auditoría.
Preguntas Frecuentes Técnicas: ¿Cómo verifico en FMEA Tool que un control predictivo o de diagnóstico merece la nota de Ocurrencia o Detección más baja que le asigné?
Documente las hipótesis detrás de la nota: horizonte pronóstico frente a tiempo de respuesta, latencia de los datos, tasas esperadas de falsa alarma y de fallo no detectado, y los objetivos de ciberseguridad de la TARA que protegen la ruta de datos. Modele el diagnóstico como elemento separado de la Estructura y analice sus propios modos de fallo; luego confirme que la Prioridad de Acción sigue teniendo sentido con esos fallos incluidos. Valide con evidencia de campo o de banco que usted haya recogido realmente; nunca use afirmaciones del proveedor como prueba. Si falta evidencia, o la monitorización se degrada en operación, vuelva a la nota original y a la inspección por tiempo, actualice la entrada del catálogo y exporte una nueva revisión del Excel para que el cambio quede trazable.
Más Artículos Técnicos en fmeatool.com
AMDEC pour le diagnostic autonome, la maintenance prédictive et la sécurité inter-couches : architecture de référence
Lorsqu’un diagnostic embarqué ou un modèle de maintenance prédictive figure comme maîtrise dans une AMDEC produit ou processus, la question principale est de savoir s’il réduit réellement l’Occurrence (prévention) ou s’il améliore seulement la Détection. La réponse détermine aussi si le diagnostic lui-même, et le chemin de données dont il dépend, doivent faire l’objet de leur propre analyse de défaillances et de menaces. Cet article relie la méthode en 7 étapes du manuel AMDEC AIAG & VDA (1re éd., 2019) et de l’IEC 60812:2018 à la couverture de diagnostic de l’ISO 26262:2018, aux flux de surveillance d’état de l’ISO 13374 et de l’ISO 17359:2018 et à la TARA de l’ISO/SAE 21434:2021, afin que chaque maîtrise créditée dans FMEA Tool puisse être justifiée et auditée.
Prévention ou détection, critère de décision
ne créditez un modèle pronostique comme maîtrise de prévention (O plus faible) que s’il déclenche une action de maintenance avant que le mode de défaillance puisse survenir et si l’avance qu’il fournit dépasse le temps nécessaire pour agir (horizon pronostique > temps de réponse). S’il ne fait que signaler une défaillance déjà amorcée, cotez-le en Détection. Si les données d’entrée peuvent être falsifiées, retardées ou perdues, ajoutez le diagnostic comme élément de Structure à part entière à l’étape 2 et analysez-y ses propres modes de défaillance : donnée périmée, capteur figé, dérive du modèle ou message manipulé.
Checklist avant mise en œuvre
avant de coter une maîtrise, recueillez la fréquence d’échantillonnage et la latence du capteur, la couche de traitement ISO 13374 où la décision est prise (acquisition des données → détection d’état → évaluation de l’état de santé → pronostic), le comportement attendu en fausses alarmes et en non-détections, les éventuels objectifs de couverture de diagnostic ISO 26262 et les objectifs de cybersécurité issus de votre TARA ISO/SAE 21434. Enregistrez chacun de ces éléments comme entrée de catalogue réutilisable, pour que les mêmes hypothèses s’appliquent à toutes les AMDEC produit et processus.
Scénario analytique illustratif (pas de données mesurées)
un mode de défaillance de roulement de broche a S=8. Un modèle de tendance vibratoire avec un horizon pronostique supposé de 72 h et une fenêtre de maintenance de 24 h justifie de passer O de 6 à 3. Le chemin CAN qui transporte ses alertes n’est pas authentifié : un mode de défaillance distinct (« alerte supprimée ou falsifiée ») reste donc à D=7 jusqu’à l’ajout d’une authentification des messages, par exemple AUTOSAR SecOC. Plan de reprise : en cas de perte des entrées du modèle, revenir à l’inspection à intervalle fixe et rétablir la cotation O d’origine. Recalculez la Priorité d’Action, puis exportez le fichier Excel comme preuve d’audit.
FAQ Technique: Comment vérifier dans FMEA Tool qu’une maîtrise prédictive ou de diagnostic mérite la cotation d’Occurrence ou de Détection plus basse que je lui ai attribuée ?
Notez les hypothèses qui sous-tendent la cotation : horizon pronostique face au temps de réponse, latence des données, taux attendus de fausses alarmes et de non-détections, et objectifs de cybersécurité de la TARA qui protègent le chemin de données. Modélisez le diagnostic comme élément de Structure distinct et analysez ses propres modes de défaillance, puis vérifiez que la Priorité d’Action reste cohérente une fois ces défaillances prises en compte. Validez avec des preuves terrain ou banc d’essai que vous avez réellement recueillies ; n’utilisez jamais les affirmations d’un fournisseur comme preuve. Si les preuves manquent, ou si la surveillance se dégrade en exploitation, revenez à la cotation d’origine et à l’inspection périodique, mettez à jour l’entrée du catalogue et exportez une nouvelle révision Excel pour garder la trace du changement.
Plus d'Articles Techniques sur fmeatool.com
FMEA per diagnostica autonoma, manutenzione predittiva e sicurezza cross-layer: architettura di riferimento
Quando una diagnostica di bordo o un modello di manutenzione predittiva compare come controllo in una DFMEA o PFMEA, la domanda principale è se riduca davvero l’Occorrenza (prevenzione) o migliori soltanto la Rilevabilità. La risposta stabilisce anche se la diagnostica stessa, e il percorso dati da cui dipende, richiedano una propria analisi di guasti e minacce. Questo articolo collega il metodo in 7 passi del Manuale FMEA AIAG & VDA (1ª ed., 2019) e della IEC 60812:2018 alla copertura diagnostica della ISO 26262:2018, ai flussi di monitoraggio delle condizioni della ISO 13374 e della ISO 17359:2018 e alla TARA della ISO/SAE 21434:2021, così che ogni controllo accreditato in FMEA Tool sia giustificabile e verificabile in audit.
Prevenzione o rilevazione, criterio di decisione
accreditate un modello prognostico come controllo di prevenzione (O più bassa) solo se attiva un intervento di manutenzione prima che il modo di guasto possa verificarsi e se l’anticipo che offre supera il tempo necessario per intervenire (orizzonte prognostico > tempo di risposta). Se segnala soltanto un guasto già iniziato, valutatelo in Rilevabilità. Se i dati in ingresso possono essere falsificati, ritardati o persi, inserite la diagnostica come elemento autonomo della Struttura al Passo 2 e analizzatene lì i modi di guasto: dato obsoleto, sensore bloccato, deriva del modello o messaggio manipolato.
Checklist pre-implementazione
prima di valutare un controllo, raccogliete frequenza di campionamento e latenza del sensore, il livello di elaborazione ISO 13374 in cui viene presa la decisione (acquisizione dati → rilevamento dello stato → valutazione dello stato di salute → prognosi), il comportamento atteso in termini di falsi allarmi e mancate rilevazioni, gli eventuali obiettivi di copertura diagnostica ISO 26262 e gli obiettivi di cybersecurity della vostra TARA ISO/SAE 21434. Registrate ciascun elemento come voce di catalogo riutilizzabile, così che le stesse ipotesi valgano in tutte le DFMEA e PFMEA.
Scenario analitico illustrativo (non sono dati misurati)
un modo di guasto del cuscinetto mandrino ha S=8. Un modello di trend vibrazionale con orizzonte prognostico ipotizzato di 72 h e finestra di manutenzione di 24 h giustifica la riduzione di O da 6 a 3. Il percorso CAN che trasporta i suoi allarmi non è autenticato, quindi un modo di guasto separato ('allarme soppresso o contraffatto') resta a D=7 finché non si aggiunge l’autenticazione dei messaggi, per esempio AUTOSAR SecOC. Piano di ripristino: se si perdono gli ingressi del modello, tornare all’ispezione a intervallo fisso e ripristinare la O originale. Ricalcolate la Priorità d’Azione ed esportate l’Excel come evidenza di audit.
FAQ Tecnica: Come verifico in FMEA Tool che un controllo predittivo o diagnostico meriti il punteggio di Occorrenza o Rilevabilità più basso che gli ho assegnato?
Documentate le ipotesi alla base del punteggio: orizzonte prognostico rispetto al tempo di risposta, latenza dei dati, tassi attesi di falsi allarmi e mancate rilevazioni, e obiettivi di cybersecurity della TARA che proteggono il percorso dati. Modellate la diagnostica come elemento separato della Struttura e analizzatene i modi di guasto, poi verificate che la Priorità d’Azione resti sensata una volta inclusi questi guasti. Convalidate con evidenze di campo o di banco che avete effettivamente raccolto; non usate mai le dichiarazioni del fornitore come prova. Se mancano evidenze, o il monitoraggio si degrada in esercizio, tornate al punteggio originale e all’ispezione a tempo, aggiornate la voce di catalogo ed esportate una nuova revisione Excel per rendere tracciabile la modifica.
Altri Articoli Tecnici su fmeatool.com
FMEA für autonome Diagnose, vorausschauende Instandhaltung und schichtübergreifende Security: eine Referenzarchitektur
Wird eine On-Board-Diagnose oder ein Predictive-Maintenance-Modell in einer DFMEA oder PFMEA als Maßnahme geführt, lautet die Kernfrage: Senkt sie tatsächlich das Auftreten (Vermeidung), oder verbessert sie nur die Entdeckung? Die Antwort entscheidet auch, ob die Diagnose selbst und der Datenpfad, auf den sie angewiesen ist, eine eigene Fehler- und Bedrohungsanalyse brauchen. Dieser Artikel verknüpft die 7-Schritt-Methode des AIAG & VDA FMEA-Handbuchs (1. Ausg., 2019) und der IEC 60812:2018 mit der Diagnoseabdeckung nach ISO 26262:2018, den Zustandsüberwachungs-Datenflüssen nach ISO 13374 und ISO 17359:2018 sowie der TARA nach ISO/SAE 21434:2021, damit jede in FMEA Tool angerechnete Maßnahme begründbar und auditierbar ist.
Vermeidung oder Entdeckung, Entscheidungskriterium
Rechnen Sie ein Prognosemodell nur dann als Vermeidungsmaßnahme an (niedrigeres A), wenn es eine Instandhaltungsmaßnahme auslöst, bevor die Fehlerart eintreten kann, und wenn seine Vorwarnzeit länger ist als die Zeit, die zum Handeln nötig ist (Prognosehorizont > Reaktionszeit). Meldet es nur einen bereits begonnenen Fehler, bewerten Sie es unter Entdeckung. Können die Eingangsdaten gefälscht werden, verspätet ankommen oder ausfallen, nehmen Sie die Diagnose in Schritt 2 als eigenes Strukturelement auf und analysieren dort ihre Fehlerarten: veraltete Daten, hängender Sensor, Modelldrift oder manipulierte Nachricht.
Checkliste vor der Umsetzung
Bevor Sie eine Maßnahme bewerten, erfassen Sie Abtastrate und Latenz des Sensors, die ISO-13374-Verarbeitungsebene, auf der entschieden wird (Datenerfassung → Zustandserkennung → Zustandsbewertung → Prognose), das erwartete Verhalten bei Fehlalarmen und Nichterkennungen, etwaige Ziele für die Diagnoseabdeckung nach ISO 26262 und die Cybersecurity-Ziele aus Ihrer TARA nach ISO/SAE 21434. Legen Sie jeden Punkt als wiederverwendbaren Katalogeintrag an, damit in allen DFMEAs und PFMEAs dieselben Annahmen gelten.
Illustratives Analyseszenario (keine Messdaten)
Eine Fehlerart am Spindellager hat B=8. Ein Vibrationstrend-Modell mit angenommenem Prognosehorizont von 72 h und einem Wartungsfenster von 24 h rechtfertigt die Senkung von A von 6 auf 3. Der CAN-Pfad, der seine Warnungen überträgt, ist nicht authentisiert, deshalb bleibt eine separate Fehlerart („Warnung unterdrückt oder gefälscht“) bei E=7, bis eine Nachrichtenauthentisierung ergänzt ist, zum Beispiel AUTOSAR SecOC. Wiederanlaufplan: Fallen die Modelleingänge aus, auf Inspektion im festen Intervall zurückgehen und die ursprüngliche A-Bewertung wiederherstellen. Aufgabenpriorität neu berechnen und den Excel-Export als Auditnachweis ablegen.
Technische FAQ: Wie prüfe ich in FMEA Tool, ob eine prädiktive oder diagnostische Maßnahme die niedrigere Auftretens- oder Entdeckungsbewertung verdient, die ich ihr gegeben habe?
Halten Sie die Annahmen hinter der Bewertung fest: Prognosehorizont gegenüber Reaktionszeit, Datenlatenz, erwartete Fehlalarm- und Nichterkennungsraten sowie die TARA-Cybersecurity-Ziele, die den Datenpfad schützen. Modellieren Sie die Diagnose als separates Strukturelement und analysieren Sie ihre eigenen Fehlerarten; prüfen Sie dann, ob die Aufgabenpriorität unter Einbeziehung dieser Fehler noch stimmig ist. Validieren Sie mit Feld- oder Prüfstandsdaten, die Sie tatsächlich erhoben haben; verwenden Sie Herstellerangaben nie als Nachweis. Fehlen Nachweise oder verschlechtert sich die Überwachung im Betrieb, kehren Sie zur ursprünglichen Bewertung und zur zeitbasierten Inspektion zurück, aktualisieren den Katalogeintrag und exportieren eine neue Excel-Revision, damit die Änderung nachvollziehbar bleibt.
Weitere Fachartikel auf fmeatool.com
将 FMEA 用于自主诊断、预测性维护与跨层安全：参考架构
当车载诊断或预测性维护模型作为控制措施列入 DFMEA 或 PFMEA 时，核心问题是：它是真的降低了发生度（预防），还是只提高了探测度？这个答案还决定了诊断功能本身及其依赖的数据路径是否需要单独做失效与威胁分析。本文把 AIAG & VDA FMEA 手册（2019 年第 1 版）和 IEC 60812:2018 的七步法，与 ISO 26262:2018 的诊断覆盖率、ISO 13374 和 ISO 17359:2018 的状态监测数据流，以及 ISO/SAE 21434:2021 的 TARA 衔接起来，使在 FMEA Tool 中记入的每项控制措施都有依据、可供审核。
预防还是探测，判定标准
只有当预测模型能在失效模式可能发生之前触发维护措施，且它提供的提前量大于采取行动所需的时间（预测时域 > 响应时间）时，才可将其记为预防控制（降低 O）。如果它只能报告已经开始的失效，就按探测度评分。如果输入数据可能被伪造、延迟或丢失，应在第 2 步把诊断功能作为独立的结构要素加入，并在那里分析它自身的失效模式：数据过时、传感器卡滞、模型漂移或报文被篡改。
实施前检查清单
在给控制措施评分前，先收集传感器的采样率和延迟、做出决策的 ISO 13374 处理层级（数据采集 → 状态检测 → 健康评估 → 预测）、预期的误报和漏报表现、ISO 26262 中可能适用的诊断覆盖率目标，以及 ISO/SAE 21434 TARA 得出的网络安全目标。把每一项都存为可复用的目录条目，让所有 DFMEA 和 PFMEA 使用同一套假设。
示例性分析场景（非实测数据）
主轴轴承的某一失效模式 S=8。假设振动趋势模型的预测时域为 72 小时，维护窗口为 24 小时，据此可将 O 从 6 降到 3。传输其报警的 CAN 路径没有认证，因此另列的失效模式「报警被屏蔽或伪造」在加入报文认证（例如 AUTOSAR SecOC）之前保持 D=7。恢复计划：模型输入丢失时，退回固定周期点检，并恢复原来的 O 评分。重新计算措施优先级，并导出 Excel 作为审核证据。
技术常见问题 (FAQ): 在 FMEA Tool 中，如何验证某项预测性或诊断控制措施确实配得上我给它的较低发生度或探测度评分？
把评分背后的假设写下来：预测时域与响应时间的对比、数据延迟、预期的误报率和漏报率，以及保护数据路径的 TARA 网络安全目标。把诊断功能建成独立的结构要素并分析其自身失效模式，然后确认纳入这些失效后措施优先级是否仍然合理。用您实际采集的现场或台架证据来验证，不要把供应商的说法当作证据。如果证据不足，或运行中监测能力下降，就退回原评分和定期点检，更新目录条目，并导出新的 Excel 版本，使变更可追溯。
更多技术文章： fmeatool.com
自律診断・予知保全・レイヤー横断セキュリティのための FMEA：リファレンスアーキテクチャ
車載診断や予知保全モデルを DFMEA・PFMEA の管理策として記載するとき、最も重要なのは、それが本当に発生度を下げる（予防）のか、それとも検出度を改善するだけなのかという点です。この判断によって、診断機能そのものと、それが依存するデータ経路にも独自の故障・脅威分析が必要かどうかも決まります。本稿では、AIAG & VDA FMEA ハンドブック（2019 年第 1 版）と IEC 60812:2018 の 7 ステップ手法を、ISO 26262:2018 の診断カバレッジ、ISO 13374 と ISO 17359:2018 の状態監視データフロー、ISO/SAE 21434:2021 の TARA と結び付け、FMEA Tool で評価に反映した各管理策の根拠を示し監査できるようにします。
予防か検出か、判定基準
予測モデルを予防管理（O の引き下げ）として評価してよいのは、故障モードが起こり得る前に保全処置を起動でき、かつモデルが示す予兆の先行時間が対処に必要な時間より長い場合（予測ホライズン > 対応時間）に限ります。すでに始まった故障を知らせるだけなら検出度で評価します。入力データが偽装・遅延・欠落し得る場合は、ステップ 2 で診断機能を独立した構造要素として追加し、そこで診断自体の故障モード（データの陳腐化、センサー固着、モデルドリフト、メッセージ改ざん）を分析します。
導入前チェックリスト
管理策を評価する前に、センサーのサンプリングレートと遅延、判断を下す ISO 13374 の処理層（データ取得 → 状態検出 → 健全性評価 → 予測）、想定される誤報・見逃しの傾向、該当する場合は ISO 26262 の診断カバレッジ目標、そして ISO/SAE 21434 の TARA から得たサイバーセキュリティ目標を集めてください。各項目を再利用可能なカタログ項目として登録し、すべての DFMEA・PFMEA で同じ前提を使えるようにします。
説明用の分析シナリオ（実測データではありません）
主軸ベアリングのある故障モードが S=8 だとします。振動トレンドモデルの予測ホライズンを 72 時間、保全ウィンドウを 24 時間と仮定すると、O を 6 から 3 に下げる根拠になります。警報を運ぶ CAN 経路には認証がないため、別に立てた故障モード「警報の抑止または偽造」は、メッセージ認証（例：AUTOSAR SecOC）を追加するまで D=7 のままにします。復旧計画：モデル入力が失われたら定期点検に戻し、O を元の評価に戻します。処置優先度を再計算し、Excel を監査証跡としてエクスポートします。
技術FAQ: FMEA Tool で、予知保全や診断の管理策に付けた低い発生度・検出度の評価が妥当かどうかを、どう検証すればよいですか？
評価の前提を記録します。予測ホライズンと対応時間の比較、データ遅延、想定される誤報率と見逃し率、データ経路を守る TARA のサイバーセキュリティ目標です。診断機能を独立した構造要素としてモデル化してその故障モードを分析し、それらを含めても処置優先度が妥当かを確認します。検証には実際に自分たちで集めたフィールドまたは台上試験の証拠を使い、サプライヤーの主張を証拠として扱わないでください。証拠が不足している場合や運用中に監視機能が劣化した場合は、元の評価と時間基準の点検に戻し、カタログ項目を更新し、新しい Excel 版をエクスポートして変更を追跡できるようにします。
その他の技術記事： fmeatool.com
자율 진단·예지 보전·계층 간 보안을 위한 FMEA: 레퍼런스 아키텍처
차량 탑재 진단이나 예지 보전 모델을 DFMEA·PFMEA의 관리 대책으로 올릴 때 핵심 질문은, 그것이 실제로 발생도를 낮추는지(예방) 아니면 검출도만 개선하는지입니다. 이 판단에 따라 진단 기능 자체와 그 기능이 의존하는 데이터 경로에도 별도의 고장·위협 분석이 필요한지가 결정됩니다. 이 글은 AIAG & VDA FMEA 핸드북(2019년 초판)과 IEC 60812:2018의 7단계 방법을 ISO 26262:2018의 진단 커버리지, ISO 13374 및 ISO 17359:2018의 상태 감시 데이터 흐름, ISO/SAE 21434:2021의 TARA와 연결하여, FMEA Tool에서 평가에 반영한 모든 관리 대책의 근거를 제시하고 감사할 수 있도록 합니다.
예방인가 검출인가, 판단 기준
예측 모델을 예방 관리(O 하향)로 인정하려면, 고장 모드가 일어나기 전에 정비 조치를 일으킬 수 있고 모델이 주는 사전 경고 시간이 조치에 필요한 시간보다 길어야 합니다(예측 호라이즌 > 대응 시간). 이미 시작된 고장을 알리기만 한다면 검출도로 평가합니다. 입력 데이터가 위조·지연·누락될 수 있다면 2단계에서 진단 기능을 독립된 구조 요소로 추가하고, 그 자체의 고장 모드(오래된 데이터, 센서 고착, 모델 드리프트, 메시지 변조)를 그곳에서 분석합니다.
도입 전 체크리스트
관리 대책을 평가하기 전에 센서의 샘플링 속도와 지연, 결정이 내려지는 ISO 13374 처리 계층(데이터 수집 → 상태 검출 → 건전성 평가 → 예측), 예상되는 오경보·미검출 경향, 해당되는 경우 ISO 26262 진단 커버리지 목표, ISO/SAE 21434 TARA에서 도출한 사이버보안 목표를 수집하십시오. 각 항목을 재사용 가능한 카탈로그 항목으로 등록해 모든 DFMEA·PFMEA에서 같은 전제를 쓰도록 합니다.
예시용 분석 시나리오(실측 데이터 아님)
스핀들 베어링의 한 고장 모드가 S=8이라고 합시다. 진동 추세 모델의 예측 호라이즌을 72시간, 정비 윈도를 24시간으로 가정하면 O를 6에서 3으로 낮출 근거가 됩니다. 경보를 전달하는 CAN 경로에 인증이 없으므로, 별도로 세운 고장 모드 「경보 차단 또는 위조」는 메시지 인증(예: AUTOSAR SecOC)을 추가할 때까지 D=7로 유지합니다. 복구 계획: 모델 입력이 끊기면 고정 주기 점검으로 돌아가고 O를 원래 평가로 되돌립니다. 조치 우선순위를 다시 계산하고 Excel을 감사 증거로 내보냅니다.
기술 FAQ: FMEA Tool에서 예지 보전이나 진단 관리 대책에 준 낮은 발생도·검출도 평가가 타당한지 어떻게 검증합니까?
평가의 전제를 기록하십시오. 예측 호라이즌과 대응 시간의 비교, 데이터 지연, 예상 오경보율과 미검출률, 데이터 경로를 보호하는 TARA 사이버보안 목표입니다. 진단 기능을 별도의 구조 요소로 모델링해 그 고장 모드를 분석한 뒤, 이를 포함해도 조치 우선순위가 여전히 타당한지 확인합니다. 검증에는 직접 수집한 현장 또는 벤치 시험 증거를 사용하고, 공급업체의 주장을 증거로 삼지 마십시오. 증거가 부족하거나 운용 중 감시 기능이 저하되면 원래 평가와 시간 기반 점검으로 되돌리고, 카탈로그 항목을 갱신하고, 새 Excel 개정판을 내보내 변경을 추적할 수 있게 하십시오.