FMEA for Edge Compute Offloading: Protocol Conformance and Production SLA Failure Modes
Moving inspection, analytics or control logic from a machine to an edge or MEC node (ETSI GS MEC 003) adds new failure modes: latency budget breaches, protocol non-conformance and SLA drift between lab and production. FMEA Tool lets you put these risks through the 7-step AIAG & VDA FMEA Handbook (1st ed., 2019) method, consistent with IEC 60812:2018. Each offloaded function becomes a measurable requirement, and Action Priority (AP) decides where mitigation must happen before rollout. Transport and protocol assumptions should point to MQTT Version 5.0 (OASIS, 2019), OPC UA (IEC 62541), QUIC (RFC 9000) or 3GPP TS 23.501, not to vendor datasheets.
Offload decision criteria
Offload a function only when its end-to-end budget (sensor → decision → actuator) can be written as a percentile requirement, for example p99 plus jitter and loss limits, and when a defined fallback exists for a missed deadline. If a failure effect is rated Severity 9–10 or touches a safety function under ISO 26262:2018 or IEC 61508:2010, keep a deterministic local path. Use the edge only for non-safety analytics or advisory results, and record that boundary as a Step 3 function requirement.
Pre-implementation checklist and recovery
Before you specify the architecture, gather the p99 latency budget, the jitter tolerance, the packet loss and link-outage profile, the MQTT 5.0 QoS level and Session Expiry Interval, the OPC UA security and transport profiles, and the clock sync source. Catalog failure modes such as silent QoS downgrade, message loss when a session expires, broker failover reordering and timestamp drift. Pair each with prevention controls (store-and-forward buffers, idempotent consumers, a local watchdog that fails safe) and detection controls (conformance test suites, contract tests, production p99 telemetry alarms). Roll out one cell or line at a time, with a documented way to revert to local processing.
Illustrative scenario (analytical, not measured)
A vision inspection station sends inference to an on-site MEC node with an assumed 50 ms p99 budget before the part leaves the station. Failure mode: "result arrives after the part has left", so a defective part escapes downstream. Illustrative ratings are S=8, O=6 and D=7, which falls in the High AP band of the AIAG & VDA table. The justified action is a local timer: no verdict within the budget means the part is diverted to a reject or quarantine lane. That turns a latency failure into a safe, detectable outcome. Then rate O and D again from production evidence, not from vendor benchmarks.
Technical FAQ: How do I check that an edge-offloading FMEA in fmeatool reflects production SLAs and not lab benchmarks?
Write each SLA as a function requirement with a percentile, a measurement window and a measurement point (for example p99 end-to-end over a shift, measured at the actuator). Accept as detection controls only methods that observe the real system: production telemetry, conformance tests run against the deployed broker or server, and fault-injection drills. Treat lab or vendor numbers as assumptions, not evidence for Occurrence. When production p99, loss rates or protocol versions change, reopen the affected failure chains, re-rate S/O/D, check the resulting Action Priority again, and export the updated Excel worksheet as the audit trail for the change.
More Technical Articles on fmeatool.com
FMEA para processamento em edge: modos de falha de conformidade de protocolo e SLA de produção
Levar inspeção, analytics ou lógica de controle da máquina para um nó edge/MEC (ETSI GS MEC 003) traz novos modos de falha: estouro do orçamento de latência, não conformidade de protocolo e desvio de SLA entre laboratório e produção. O FMEA Tool permite tratar esses riscos com o método de 7 passos do AIAG & VDA FMEA Handbook (1ª ed., 2019), alinhado à IEC 60812:2018. Cada função processada no edge vira um requisito mensurável, e a Action Priority (AP) define onde a mitigação deve acontecer antes do rollout. As premissas de transporte e protocolo devem citar MQTT Version 5.0 (OASIS, 2019), OPC UA (IEC 62541), QUIC (RFC 9000) ou 3GPP TS 23.501, não datasheets de fornecedor.
Critérios para levar uma função ao edge
Faça isso só quando o orçamento ponta a ponta (sensor → decisão → atuador) puder ser escrito como requisito em percentil, por exemplo p99 mais limites de jitter e perda, e quando houver um fallback definido para prazo perdido. Se o efeito tiver Severidade 9–10 ou envolver uma função de segurança sob ISO 26262:2018 ou IEC 61508:2010, mantenha um caminho local determinístico. Use o edge só para analytics ou resultados consultivos sem papel de segurança, e registre essa fronteira como requisito de função no Passo 3.
Checklist antes de implementar e recuperação
Antes de especificar a arquitetura, levante o orçamento de latência p99, a tolerância a jitter, o perfil de perda de pacotes e de queda de link, o nível de QoS e o Session Expiry Interval do MQTT 5.0, os perfis de segurança e transporte do OPC UA e a fonte de sincronismo de relógio. Cadastre no catálogo modos de falha como downgrade silencioso de QoS, perda de mensagens quando a sessão expira, reordenação no failover do broker e deriva de timestamp. Associe cada um a controles de prevenção (buffer store-and-forward, consumidores idempotentes, watchdog local que leva ao estado seguro) e de detecção (suítes de conformidade, testes de contrato, alarmes de telemetria p99 em produção). Faça o rollout por célula ou linha, com um caminho documentado de volta ao processamento local.
Cenário ilustrativo (analítico, não medido)
Uma estação de inspeção por visão envia a inferência a um nó MEC na planta, com orçamento assumido de 50 ms p99 antes de a peça sair da estação. Modo de falha: "resultado chega depois que a peça saiu", então uma peça defeituosa escapa para o processo seguinte. As notas ilustrativas são S=8, O=6 e D=7, que caem na faixa de AP Alta da tabela AIAG & VDA. A ação justificada é um temporizador local: sem veredito dentro do orçamento, a peça vai para a rota de rejeito ou quarentena. Isso transforma a falha de latência em um resultado seguro e detectável. Depois, reavalie O e D com evidência de produção, não com benchmarks de fornecedor.
FAQ Técnica: Como verifico se um FMEA de processamento em edge no fmeatool reflete o SLA de produção e não benchmarks de laboratório?
Escreva cada SLA como requisito de função com percentil, janela de medição e ponto de medição (por exemplo p99 ponta a ponta por turno, medido no atuador). Aceite como controle de detecção só métodos que observam o sistema real: telemetria de produção, testes de conformidade rodados contra o broker ou servidor implantado e simulações de injeção de falhas. Trate números de laboratório ou de fornecedor como premissas, não como evidência de Ocorrência. Quando o p99, as taxas de perda ou as versões de protocolo mudarem em produção, reabra as cadeias de falha afetadas, reavalie S/O/D, confira de novo a Action Priority resultante e exporte a planilha Excel atualizada como trilha de auditoria da mudança.
Mais Artigos Técnicos em fmeatool.com
FMEA para procesamiento en edge: modos de fallo de conformidad de protocolo y SLA de producción
Llevar inspección, analítica o lógica de control desde la máquina a un nodo edge/MEC (ETSI GS MEC 003) introduce nuevos modos de fallo: rebasamiento del presupuesto de latencia, no conformidad de protocolo y deriva del SLA entre laboratorio y producción. FMEA Tool permite tratar estos riesgos con el método de 7 pasos del AIAG & VDA FMEA Handbook (1.ª ed., 2019), coherente con IEC 60812:2018. Cada función procesada en el edge se convierte en un requisito medible, y la Action Priority (AP) decide dónde mitigar antes del despliegue. Las hipótesis de transporte y protocolo deben citar MQTT Version 5.0 (OASIS, 2019), OPC UA (IEC 62541), QUIC (RFC 9000) o 3GPP TS 23.501, no hojas de datos de proveedores.
Criterios para llevar una función al edge
Hágalo solo cuando el presupuesto extremo a extremo (sensor → decisión → actuador) pueda escribirse como requisito en percentil, por ejemplo p99 más límites de jitter y pérdida, y cuando exista un fallback definido para un plazo incumplido. Si el efecto tiene Severidad 9–10 o afecta a una función de seguridad bajo ISO 26262:2018 o IEC 61508:2010, mantenga una ruta local determinista. Use el edge solo para analítica o resultados consultivos sin papel de seguridad, y registre ese límite como requisito de función en el Paso 3.
Checklist previo a la implementación y recuperación
Antes de especificar la arquitectura, reúna el presupuesto de latencia p99, la tolerancia al jitter, el perfil de pérdida de paquetes y de caída de enlace, el nivel de QoS y el Session Expiry Interval de MQTT 5.0, los perfiles de seguridad y transporte de OPC UA y la fuente de sincronización de reloj. Registre en el catálogo modos de fallo como la degradación silenciosa de QoS, la pérdida de mensajes al expirar la sesión, el reordenamiento en el failover del broker y la deriva de marcas de tiempo. Asocie cada uno a controles de prevención (buffer store-and-forward, consumidores idempotentes, watchdog local que lleva al estado seguro) y de detección (suites de conformidad, pruebas de contrato, alarmas de telemetría p99 en producción). Despliegue por celda o línea, con una vuelta documentada al procesamiento local.
Escenario ilustrativo (analítico, no medido)
Una estación de inspección por visión envía la inferencia a un nodo MEC en planta, con un presupuesto supuesto de 50 ms p99 antes de que la pieza salga de la estación. Modo de fallo: "el resultado llega después de que la pieza ha salido", así que una pieza defectuosa escapa al proceso siguiente. Las puntuaciones ilustrativas son S=8, O=6 y D=7, que caen en la banda de AP Alta de la tabla AIAG & VDA. La acción justificada es un temporizador local: sin veredicto dentro del presupuesto, la pieza se desvía a la ruta de rechazo o cuarentena. Así el fallo de latencia se convierte en un resultado seguro y detectable. Después, reevalúe O y D con evidencia de producción, no con benchmarks de proveedores.
Preguntas Frecuentes Técnicas: ¿Cómo verifico que un FMEA de procesamiento en edge en fmeatool refleja el SLA de producción y no benchmarks de laboratorio?
Escriba cada SLA como requisito de función con percentil, ventana de medición y punto de medición (por ejemplo p99 extremo a extremo por turno, medido en el actuador). Acepte como controles de detección solo métodos que observen el sistema real: telemetría de producción, pruebas de conformidad contra el broker o servidor desplegado y simulacros de inyección de fallos. Trate las cifras de laboratorio o de proveedor como hipótesis, no como evidencia de Ocurrencia. Cuando cambien en producción el p99, las tasas de pérdida o las versiones de protocolo, reabra las cadenas de fallo afectadas, reevalúe S/O/D, vuelva a comprobar la Action Priority resultante y exporte la hoja Excel actualizada como registro de auditoría del cambio.
Más Artículos Técnicos en fmeatool.com
AMDEC du déport de calcul vers l'edge : modes de défaillance liés à la conformité protocolaire et aux SLA de production
Déporter l'inspection, l'analytique ou la logique de commande d'une machine vers un nœud edge/MEC (ETSI GS MEC 003) introduit de nouveaux modes de défaillance : dépassement du budget de latence, non-conformité protocolaire et dérive des SLA entre laboratoire et production. FMEA Tool permet de traiter ces risques avec la méthode en 7 étapes de l'AIAG & VDA FMEA Handbook (1re éd., 2019), cohérente avec l'IEC 60812:2018. Chaque fonction déportée devient une exigence mesurable, et l'Action Priority (AP) indique où agir avant le déploiement. Les hypothèses de transport et de protocole doivent s'appuyer sur MQTT Version 5.0 (OASIS, 2019), OPC UA (IEC 62541), QUIC (RFC 9000) ou 3GPP TS 23.501, et non sur des fiches fournisseur.
Critères de décision du déport
Ne déportez une fonction que si son budget de bout en bout (capteur → décision → actionneur) peut s'écrire comme une exigence en percentile, par exemple p99 avec des limites de gigue et de perte, et si un repli est défini en cas d'échéance manquée. Si l'effet est coté en Gravité 9–10 ou touche une fonction de sécurité au sens de l'ISO 26262:2018 ou de l'IEC 61508:2010, conservez un chemin local déterministe. Réservez l'edge à l'analytique ou aux résultats consultatifs sans rôle de sécurité, et inscrivez cette frontière comme exigence de fonction à l'étape 3.
Checklist avant la mise en œuvre et reprise
Avant de spécifier l'architecture, rassemblez le budget de latence p99, la tolérance à la gigue, le profil de perte de paquets et de coupure de lien, le niveau de QoS et le Session Expiry Interval MQTT 5.0, les profils de sécurité et de transport OPC UA et la source de synchronisation d'horloge. Cataloguez des modes de défaillance comme la dégradation silencieuse de QoS, la perte de messages à l'expiration de la session, le réordonnancement lors du basculement du broker et la dérive d'horodatage. Associez à chacun des contrôles de prévention (tampon store-and-forward, consommateurs idempotents, watchdog local qui ramène à l'état sûr) et de détection (suites de conformité, tests de contrat, alarmes de télémétrie p99 en production). Déployez cellule par cellule ou ligne par ligne, avec un retour documenté au traitement local.
Scénario illustratif (analytique, non mesuré)
Un poste d'inspection par vision envoie l'inférence à un nœud MEC sur site, avec un budget supposé de 50 ms p99 avant que la pièce ne quitte le poste. Mode de défaillance : « le résultat arrive après la sortie de la pièce », si bien qu'une pièce défectueuse passe à l'aval. Les cotations illustratives sont S=8, O=6 et D=7, ce qui tombe dans la zone d'AP Haute du tableau AIAG & VDA. L'action justifiée est une temporisation locale : sans verdict dans le budget, la pièce part vers la voie de rebut ou de quarantaine. La défaillance de latence devient ainsi un résultat sûr et détectable. Recotez ensuite O et D à partir de preuves de production, et non de benchmarks fournisseur.
FAQ Technique: Comment vérifier qu'une AMDEC de déport vers l'edge dans fmeatool reflète les SLA de production et non des benchmarks de laboratoire ?
Rédigez chaque SLA comme une exigence de fonction avec un percentile, une fenêtre de mesure et un point de mesure (par exemple p99 de bout en bout par poste de travail, mesuré à l'actionneur). N'acceptez comme contrôles de détection que des méthodes qui observent le système réel : télémétrie de production, tests de conformité menés contre le broker ou le serveur déployé et exercices d'injection de fautes. Traitez les chiffres de laboratoire ou de fournisseur comme des hypothèses, pas comme des preuves d'Occurrence. Quand le p99, les taux de perte ou les versions de protocole changent en production, rouvrez les chaînes de défaillance concernées, recotez S/O/D, revérifiez l'Action Priority obtenue et exportez la feuille Excel mise à jour comme trace d'audit du changement.
Plus d'Articles Techniques sur fmeatool.com
FMEA per l'offloading di calcolo all'edge: modi di guasto legati alla conformità di protocollo e agli SLA di produzione
Spostare ispezione, analytics o logica di controllo dalla macchina a un nodo edge/MEC (ETSI GS MEC 003) introduce nuovi modi di guasto: sforamento del budget di latenza, non conformità di protocollo e deriva degli SLA tra laboratorio e produzione. FMEA Tool permette di trattare questi rischi con il metodo in 7 passi dell'AIAG & VDA FMEA Handbook (1ª ed., 2019), coerente con la IEC 60812:2018. Ogni funzione spostata all'edge diventa un requisito misurabile, e l'Action Priority (AP) stabilisce dove intervenire prima del rollout. Le ipotesi di trasporto e protocollo devono citare MQTT Version 5.0 (OASIS, 2019), OPC UA (IEC 62541), QUIC (RFC 9000) o 3GPP TS 23.501, non i datasheet dei fornitori.
Criteri per spostare una funzione all'edge
Fatelo solo quando il budget end-to-end (sensore → decisione → attuatore) si può scrivere come requisito in percentile, per esempio p99 con limiti di jitter e perdita, e quando esiste un fallback definito per la scadenza mancata. Se l'effetto ha Severità 9–10 o riguarda una funzione di sicurezza secondo ISO 26262:2018 o IEC 61508:2010, mantenete un percorso locale deterministico. Usate l'edge solo per analytics o risultati consultivi senza ruolo di sicurezza, e registrate questo confine come requisito di funzione nel Passo 3.
Checklist prima dell'implementazione e ripristino
Prima di specificare l'architettura, raccogliete il budget di latenza p99, la tolleranza al jitter, il profilo di perdita pacchetti e di interruzione del link, il livello di QoS e il Session Expiry Interval di MQTT 5.0, i profili di sicurezza e trasporto OPC UA e la sorgente di sincronizzazione dell'orologio. Inserite nel catalogo modi di guasto come il declassamento silenzioso della QoS, la perdita di messaggi alla scadenza della sessione, il riordino durante il failover del broker e la deriva dei timestamp. Associate a ciascuno controlli di prevenzione (buffer store-and-forward, consumer idempotenti, watchdog locale che porta allo stato sicuro) e di rilevazione (suite di conformità, contract test, allarmi di telemetria p99 in produzione). Fate il rollout per cella o per linea, con un ritorno documentato all'elaborazione locale.
Scenario illustrativo (analitico, non misurato)
Una stazione di ispezione visiva invia l'inferenza a un nodo MEC in stabilimento, con un budget ipotizzato di 50 ms p99 prima che il pezzo lasci la stazione. Modo di guasto: "il risultato arriva dopo che il pezzo è uscito", quindi un pezzo difettoso sfugge a valle. I punteggi illustrativi sono S=8, O=6 e D=7, che ricadono nella fascia di AP Alta della tabella AIAG & VDA. L'azione giustificata è un timer locale: senza verdetto entro il budget, il pezzo viene deviato sulla linea di scarto o quarantena. Così il guasto di latenza diventa un esito sicuro e rilevabile. Poi rivalutate O e D con evidenze di produzione, non con benchmark dei fornitori.
FAQ Tecnica: Come verifico che una FMEA di offloading all'edge in fmeatool rifletta gli SLA di produzione e non benchmark di laboratorio?
Scrivete ogni SLA come requisito di funzione con percentile, finestra di misura e punto di misura (per esempio p99 end-to-end per turno, misurato all'attuatore). Accettate come controlli di rilevazione solo metodi che osservano il sistema reale: telemetria di produzione, test di conformità eseguiti sul broker o server installato ed esercitazioni di fault injection. Trattate i numeri di laboratorio o dei fornitori come ipotesi, non come evidenza di Occorrenza. Quando in produzione cambiano il p99, i tassi di perdita o le versioni di protocollo, riaprite le catene di guasto interessate, rivalutate S/O/D, ricontrollate l'Action Priority risultante ed esportate il foglio Excel aggiornato come traccia di audit della modifica.
Altri Articoli Tecnici su fmeatool.com
FMEA für Edge-Compute-Offloading: Fehlerarten bei Protokollkonformität und Produktions-SLAs
Wer Prüfung, Analytik oder Steuerlogik von der Maschine auf einen Edge- bzw. MEC-Knoten (ETSI GS MEC 003) verlagert, bekommt neue Fehlerarten: überschrittene Latenzbudgets, fehlende Protokollkonformität und SLA-Drift zwischen Labor und Produktion. Mit FMEA Tool lassen sich diese Risiken nach der 7-Schritte-Methode des AIAG & VDA FMEA-Handbuchs (1. Ausg., 2019) bearbeiten, konsistent mit IEC 60812:2018. Jede ausgelagerte Funktion wird zu einer messbaren Anforderung, und die Aufgabenpriorität (AP) legt fest, wo vor dem Rollout Maßnahmen nötig sind. Annahmen zu Transport und Protokoll sollten auf MQTT Version 5.0 (OASIS, 2019), OPC UA (IEC 62541), QUIC (RFC 9000) oder 3GPP TS 23.501 verweisen, nicht auf Herstellerdatenblätter.
Entscheidungskriterien für das Offloading
Lagern Sie eine Funktion nur aus, wenn sich ihr End-to-End-Budget (Sensor → Entscheidung → Aktor) als Perzentil-Anforderung formulieren lässt, etwa p99 mit Jitter- und Verlustgrenzen, und wenn für eine verpasste Deadline ein definierter Fallback existiert. Hat die Fehlerfolge eine Bedeutung von 9–10 oder betrifft sie eine Sicherheitsfunktion nach ISO 26262:2018 bzw. IEC 61508:2010, behalten Sie einen deterministischen lokalen Pfad. Nutzen Sie die Edge nur für nicht sicherheitsrelevante Analytik oder beratende Ergebnisse, und dokumentieren Sie diese Grenze als Funktionsanforderung in Schritt 3.
Checkliste vor der Umsetzung und Wiederherstellung
Erfassen Sie vor der Architekturfestlegung das p99-Latenzbudget, die Jitter-Toleranz, das Profil für Paketverlust und Verbindungsausfall, die MQTT-5.0-QoS-Stufe und das Session Expiry Interval, die OPC-UA-Sicherheits- und Transportprofile sowie die Quelle der Zeitsynchronisation. Legen Sie im Katalog Fehlerarten an wie stille QoS-Herabstufung, Nachrichtenverlust beim Ablauf der Session, Umsortierung beim Broker-Failover und Zeitstempeldrift. Ordnen Sie jeder Fehlerart Vermeidungsmaßnahmen (Store-and-Forward-Puffer, idempotente Consumer, lokaler Watchdog mit Übergang in den sicheren Zustand) und Entdeckungsmaßnahmen zu (Konformitätstestsuiten, Contract-Tests, p99-Telemetriealarme in der Produktion). Führen Sie das Rollout zelle- oder linienweise ein, mit einem dokumentierten Rückweg zur lokalen Verarbeitung.
Illustratives Szenario (analytisch, nicht gemessen)
Eine Kamera-Prüfstation sendet die Inferenz an einen MEC-Knoten im Werk, mit einem angenommenen Budget von 50 ms p99, bevor das Teil die Station verlässt. Fehlerart: „Ergebnis kommt erst, nachdem das Teil die Station verlassen hat“, sodass ein fehlerhaftes Teil in den nächsten Prozess gelangt. Die illustrativen Bewertungen sind S=8, O=6 und D=7, was in den Bereich hoher AP der AIAG-&-VDA-Tabelle fällt. Die begründete Maßnahme ist ein lokaler Timer: Liegt innerhalb des Budgets kein Urteil vor, wird das Teil auf die Ausschuss- oder Sperrbahn geleitet. So wird aus dem Latenzfehler ein sicheres, entdeckbares Ergebnis. Bewerten Sie danach O und D anhand von Produktionsnachweisen neu, nicht anhand von Hersteller-Benchmarks.
Technische FAQ: Wie prüfe ich, ob eine Edge-Offloading-FMEA in fmeatool Produktions-SLAs widerspiegelt und nicht Labor-Benchmarks?
Formulieren Sie jedes SLA als Funktionsanforderung mit Perzentil, Messfenster und Messpunkt (z. B. p99 End-to-End pro Schicht, gemessen am Aktor). Akzeptieren Sie als Entdeckungsmaßnahmen nur Methoden, die das reale System beobachten: Produktionstelemetrie, Konformitätstests gegen den installierten Broker oder Server und Fault-Injection-Übungen. Behandeln Sie Labor- oder Herstellerwerte als Annahmen, nicht als Nachweis für das Auftreten. Ändern sich in der Produktion p99, Verlustraten oder Protokollversionen, öffnen Sie die betroffenen Fehlerketten erneut, bewerten S/O/D neu, prüfen die resultierende Aufgabenpriorität erneut und exportieren das aktualisierte Excel-Formblatt als Audit-Trail der Änderung.
Weitere Fachartikel auf fmeatool.com
边缘计算卸载的 FMEA：协议一致性与生产 SLA 失效模式
把检测、分析或控制逻辑从设备迁到边缘/MEC 节点（ETSI GS MEC 003）后，会出现新的失效模式：延迟预算超限、协议不一致，以及实验室与生产之间的 SLA 漂移。FMEA Tool 可以用 AIAG & VDA FMEA 手册（2019 年第 1 版）的七步法处理这些风险，与 IEC 60812:2018 保持一致。每个卸载到边缘的功能都写成可测量的要求，再由措施优先级（AP）决定上线前必须在哪里采取措施。传输与协议假设应引用 MQTT Version 5.0（OASIS，2019）、OPC UA（IEC 62541）、QUIC（RFC 9000）或 3GPP TS 23.501，而不是供应商数据手册。
卸载决策准则：只有当端到端预算（传感器 → 决策 → 执行器）能写成百分位要求（例如 p99 加上抖动和丢包上限），并且对错过截止时间有明确的回退方案时，才把功能卸载到边缘。如果失效后果的严重度为 9–10，或涉及 ISO 26262
2018、IEC 61508:2010 意义上的安全功能，就保留确定性的本地路径。边缘只用于不承担安全作用的分析或建议性结果，并在第 3 步把这条边界记录为功能要求。
实施前检查清单与恢复
确定架构之前，先收集 p99 延迟预算、抖动容限、丢包与链路中断特性、MQTT 5.0 的 QoS 等级和 Session Expiry Interval、OPC UA 的安全与传输配置文件，以及时钟同步源。在目录中登记以下失效模式：QoS 静默降级、会话过期导致的消息丢失、Broker 故障切换时的消息乱序、时间戳漂移。为每个失效模式配上预防控制（存储转发缓冲、幂等消费者、导向安全状态的本地看门狗）和探测控制（一致性测试套件、契约测试、生产环境的 p99 遥测告警）。按单元或产线逐步上线，并写明退回本地处理的路径。
示例场景（分析性假设，非实测）
视觉检测工位把推理请求发到厂内 MEC 节点，假设零件离开工位前的预算为 50 ms p99。失效模式是“结果在零件离开工位后才到达”，导致缺陷件流入下游。示例评分为 S=8、O=6、D=7，落在 AIAG & VDA 表的高 AP 区间。合理的措施是本地计时器：预算内没有判定结果，零件就转入拒收或隔离通道。这样延迟失效就变成了安全、可探测的结果。之后用生产数据重新评定 O 和 D，而不是用供应商基准。
技术常见问题 (FAQ): 如何确认 fmeatool 中的边缘卸载 FMEA 反映的是生产 SLA，而不是实验室基准？
把每项 SLA 写成功能要求，注明百分位、测量窗口和测量点（例如每班次端到端 p99，在执行器处测量）。探测控制只接受观察真实系统的方法：生产遥测、针对已部署 Broker 或服务器的一致性测试，以及故障注入演练。实验室或供应商的数据只能当作假设，不能当作频度的证据。生产中的 p99、丢包率或协议版本一旦变化，就重新打开受影响的失效链，重新评定 S/O/D，再次核对得出的措施优先级，并导出更新后的 Excel 表，作为这次变更的审计记录。
更多技术文章： fmeatool.com
エッジコンピューティング・オフロードのFMEA：プロトコル適合性と本番SLAの故障モード
検査、分析、制御ロジックを装置からエッジ/MECノード（ETSI GS MEC 003）へ移すと、新しい故障モードが生まれます。レイテンシ予算の超過、プロトコル不適合、ラボと本番の間のSLAのずれです。FMEA Toolでは、これらのリスクをAIAG & VDA FMEAハンドブック（第1版、2019年）の7ステップ手法で扱えます。手法はIEC 60812:2018とも整合します。オフロードする各機能を測定可能な要求として書き、処置優先度（AP）でロールアウト前に対策すべき箇所を決めます。伝送とプロトコルの前提は、ベンダーのデータシートではなく、MQTT Version 5.0（OASIS、2019）、OPC UA（IEC 62541）、QUIC（RFC 9000）、3GPP TS 23.501を根拠にしてください。
オフロード判断基準：エンドツーエンド予算（センサ → 判定 → アクチュエータ）を百分位の要求（例：p99にジッタと損失の上限を加えたもの）として書け、期限超過時のフォールバックが定義されている場合に限ってオフロードします。故障影響の厳しさが9〜10の場合や、ISO 26262
2018・IEC 61508:2010の安全機能に関わる場合は、決定論的なローカル経路を残します。エッジは安全上の役割を持たない分析や助言的な結果に限定し、その境界をステップ3の機能要求として記録します。
実装前チェックリストと復旧
アーキテクチャを決める前に、p99レイテンシ予算、ジッタ許容値、パケット損失とリンク断の特性、MQTT 5.0のQoSレベルとSession Expiry Interval、OPC UAのセキュリティ/トランスポートプロファイル、時刻同期源を収集します。カタログには、QoSの暗黙的な格下げ、セッション期限切れによるメッセージ消失、ブローカーのフェイルオーバー時の順序入れ替わり、タイムスタンプのずれといった故障モードを登録します。それぞれに予防管理（ストア&フォワードのバッファ、冪等なコンシューマ、安全状態へ移行するローカルのウォッチドッグ）と検出管理（適合性テストスイート、コントラクトテスト、本番のp99テレメトリ警報）を対応させます。ロールアウトはセルまたはライン単位で進め、ローカル処理へ戻す手順を文書化しておきます。
例示シナリオ（分析上の仮定、実測ではない）
画像検査ステーションが推論を工場内のMECノードに送り、部品がステーションを離れるまでの予算をp99で50 msと仮定します。故障モードは「部品が離れた後に結果が届く」で、不良品が後工程へ流出します。例示評価はS=8、O=6、D=7で、AIAG & VDA表のAP「高」の範囲に入ります。妥当な処置はローカルタイマーです。予算内に判定がなければ、部品をリジェクトまたは隔離レーンへ振り分けます。これでレイテンシ故障が安全で検出可能な結果に変わります。その後、OとDはベンダーのベンチマークではなく本番のデータで再評価します。
技術FAQ: fmeatoolで作ったエッジオフロードのFMEAが、ラボのベンチマークではなく本番SLAを反映しているかをどう確認すればよいですか？
各SLAを、百分位、測定ウィンドウ、測定点を明記した機能要求として書きます（例：シフトごとのエンドツーエンドp99をアクチュエータで測定）。検出管理として認めるのは、実システムを観測する方法だけです。本番テレメトリ、導入済みのブローカーやサーバに対する適合性テスト、フォールトインジェクション演習がこれに当たります。ラボやベンダーの数値は前提として扱い、発生度の根拠にはしません。本番でp99、損失率、プロトコルのバージョンが変わったら、影響する故障チェーンを開き直してS/O/Dを再評価し、得られた処置優先度を再確認して、更新したExcelシートを変更の監査証跡としてエクスポートします。
その他の技術記事： fmeatool.com
엣지 컴퓨팅 오프로딩을 위한 FMEA: 프로토콜 적합성과 운영 SLA 고장 모드
검사, 분석, 제어 로직을 설비에서 엣지/MEC 노드(ETSI GS MEC 003)로 옮기면 새로운 고장 모드가 생깁니다. 지연 예산 초과, 프로토콜 부적합, 그리고 실험실과 운영 환경 사이의 SLA 편차입니다. FMEA Tool에서는 이런 위험을 AIAG & VDA FMEA 핸드북(2019년 제1판)의 7단계 방법으로 다룰 수 있으며, 이 방법은 IEC 60812:2018과도 일치합니다. 오프로딩하는 각 기능을 측정 가능한 요구사항으로 쓰고, 조치 우선순위(AP)로 롤아웃 전에 대책이 필요한 곳을 정합니다. 전송과 프로토콜에 대한 가정은 공급업체 데이터시트가 아니라 MQTT Version 5.0(OASIS, 2019), OPC UA(IEC 62541), QUIC(RFC 9000), 3GPP TS 23.501을 근거로 삼아야 합니다.
오프로딩 결정 기준
엔드투엔드 예산(센서 → 판정 → 액추에이터)을 백분위 요구사항(예: p99에 지터·손실 한계를 더한 것)으로 쓸 수 있고, 마감 시간을 놓쳤을 때의 폴백이 정의되어 있을 때만 오프로딩합니다. 고장 영향의 심각도가 9–10이거나 ISO 26262:2018 또는 IEC 61508:2010의 안전 기능과 관련되면 결정론적 로컬 경로를 유지합니다. 엣지는 안전 역할이 없는 분석이나 권고성 결과에만 쓰고, 그 경계를 3단계의 기능 요구사항으로 기록합니다.
구현 전 체크리스트와 복구
아키텍처를 정하기 전에 p99 지연 예산, 지터 허용치, 패킷 손실과 링크 단절 특성, MQTT 5.0의 QoS 수준과 Session Expiry Interval, OPC UA 보안·전송 프로파일, 시각 동기화 소스를 수집합니다. 카탈로그에는 QoS의 무경고 강등, 세션 만료로 인한 메시지 손실, 브로커 페일오버 시 순서 뒤바뀜, 타임스탬프 드리프트 같은 고장 모드를 등록합니다. 각각에 예방 관리(저장 후 전달 버퍼, 멱등 컨슈머, 안전 상태로 전환하는 로컬 워치독)와 검출 관리(적합성 테스트 스위트, 계약 테스트, 운영 환경 p99 텔레메트리 경보)를 연결합니다. 롤아웃은 셀 또는 라인 단위로 진행하고, 로컬 처리로 되돌아가는 절차를 문서화해 둡니다.
예시 시나리오(분석적 가정, 실측 아님)
비전 검사 스테이션이 추론을 공장 내 MEC 노드로 보내고, 부품이 스테이션을 떠나기 전까지의 예산을 p99 50 ms로 가정합니다. 고장 모드는 '부품이 떠난 뒤에 결과가 도착함'이며, 그 결과 불량 부품이 후공정으로 유출됩니다. 예시 평가는 S=8, O=6, D=7로, AIAG & VDA 표의 AP '높음' 구간에 해당합니다. 타당한 조치는 로컬 타이머입니다. 예산 안에 판정이 없으면 부품을 불량 또는 격리 라인으로 보냅니다. 이렇게 하면 지연 고장이 안전하고 검출 가능한 결과로 바뀝니다. 이후 O와 D는 공급업체 벤치마크가 아니라 운영 데이터로 다시 평가합니다.
기술 FAQ: fmeatool에서 작성한 엣지 오프로딩 FMEA가 실험실 벤치마크가 아니라 운영 SLA를 반영하는지 어떻게 확인합니까?
각 SLA를 백분위, 측정 구간, 측정 지점을 명시한 기능 요구사항으로 씁니다(예: 교대별 엔드투엔드 p99를 액추에이터에서 측정). 검출 관리로는 실제 시스템을 관찰하는 방법만 인정합니다. 운영 텔레메트리, 배포된 브로커나 서버를 대상으로 한 적합성 테스트, 결함 주입 훈련이 여기에 해당합니다. 실험실이나 공급업체 수치는 가정으로만 다루고 발생도의 근거로 쓰지 않습니다. 운영 중 p99, 손실률, 프로토콜 버전이 바뀌면 영향받는 고장 사슬을 다시 열어 S/O/D를 재평가하고, 그 결과 나온 조치 우선순위를 다시 확인한 뒤, 갱신된 Excel 시트를 변경의 감사 추적으로 내보냅니다.