PaperlayerView exact revision on arXiv

Source-linked AI summary

EAST: Embodied AI Safety Testing via Systematic Fault Injection in Digital Twins

Yuhao Tian, Tao Li, Ling Zhou, Dave Towey, Zhaoxin Fan, Wenjun Wu, Rubing Huang, Tsong Yueh Chen

arXiv:2610.34358v1cs.SEcs.RO

TL;DR

Task completion does not establish safe embodied-AI execution, and existing approaches lack a systematic route from safety knowledge to executable, verifiable faults. EAST uses constrained fault injection in digital twins and assesses safety separately from task outcomes. Across five campaigns, it covered all 74 admissible task–policy–operator combinations, obtaining valid evidence for 63, while 82 valid executions completed tasks despite detected violations.

  • Problem

    Embodied-AI safety evaluation must distinguish task completion from safe execution, while existing approaches lack a systematic route from safety knowledge to executable faults.

    Source: §1 · pp. 2–3

  • Method

    EAST maps literature-grounded safety evidence to executable fault operators, verifies runtime realization, and assesses safety outcomes independently using simulator-state and trace evidence.

    Source: §2.3 · p. 7, §3.2.1 · p. 9

  • Results

    Across five campaigns, EAST covered all 74 admissible task–policy–operator combinations, obtained valid evidence for 63, and had exposure rates close to Random-Legal and Rule-Based.

    Source: §1 · p. 4

  • Takeaways & Limitations

    82 valid EAST executions completed their tasks despite detected safety violations, underscoring the need to evaluate task and safety outcomes separately.

    Source: §1 · pp. 4–5

    Experiment 4 category counts cannot be summed as distinct records because one record may contribute to multiple categories.

    Source: §6.4 · p. 32

Abstract

from arXiv · show

Task success is not a sufficient measure of safety for embodied artificial intelligence (AI), because robots may complete objectives while violating safety requirements. Existing evaluations often emphasize performance and robustness, but lack a systematic route from documented safety hazards to executable, verifiable tests. We present EAST (Embodied AI Safety Testing), a digital-twin framework that converts literature-grounded safety evidence into fault-injection tests across perception, instructions, environments, actions, and timing. EAST combines an expert-reviewed safety-fault taxonomy and eight executable operators with applicability and validity constraints. Its three-stage workflow generates test specifications, verifies fault realization during simulated execution, and independently assesses safety challenges, violations, task outcomes, and behavioral signatures using simulator-state evidence. The framework preserves execution traces and replayable records, supporting attribution and reproducibility across experiments. We evaluate EAST on six RoboTwin manipulation tasks and two policy architectures, ACT and RDT, against alternative testing strategies under matched budgets. Across five comparative campaigns, EAST targets all 74 admissible task-policy-operator combinations and obtains valid evidence for 63, while achieving safety-challenge exposure rates close to Random-Legal and Rule-Based. Moreover, 82 valid EAST executions complete their tasks despite safety violations, revealing risks concealed by success-oriented evaluation. These findings support systematic, validity-aware, reproducible safety testing beyond task-completion metrics.

1 Introduction

Task success can coexist with safety violations, while existing evaluation approaches do not provide a systematic route from safety knowledge to executable, verifiable faults. EAST addresses this gap with constrained fault-injection testing and evaluates safety separately from task outcomes.

1 Introduction

  • Task completion does not imply safe execution: existing safety benchmarks report successful but unsafe behavior, motivating tests that examine behavior under deliberately introduced safety-critical conditions.Prior robustness perturbations do not necessarily represent a defined safety fault or specify which safety requirement should be checked.Source: §1 · pp. 2–3
  • EAST’s three illustrative executions each complete the task despite a detected violation: instruction-role swapping, premature release, and a four-call delay to one arm.The images are illustrative replays of fixed configurations and were not included in quantitative analyses.Source: §1 · p. 3, Figure 1 · p. 3
  • Earlier testing approaches address complementary objectives, but systematic safety testing must connect meaningful interventions and runtime realization to the safety requirements and reproducible execution evidence.Robustness testing, safety benchmarks, red-teaming, and software-testing methods each address parts of this problem, but do not by themselves provide that full connection.Source: §1 · pp. 3–4
  • EAST builds a literature-grounded safety-fault model, maps safety obligations to eight executable operators, verifies fault realization, and assesses safety outcomes independently of task success.Test specifications are subject to applicability, validity, semantic, contextual, deduplication, and diversity constraints; findings remain linked to execution evidence and replayable records.Source: §1 · pp. 4–5
  • All 74 admissible task–policy–operator combinations were included in each of five campaigns, with valid evidence for 63 and exposure rates close to Random-Legal and Rule-Based.EAST also recorded 82 valid executions that completed their tasks despite detected safety violations.Source: §1 · p. 4

2 Preliminaries

The preliminaries frame embodied AI as closed-loop interaction between an agent and its environment, define safety independently of task completion, and introduce EAST’s fault-injection model. They establish the concepts and notation used to describe tasks, policies, safety hazards, and executable interventions.

2.1 Embodied AI Systems

  • An embodied AI system perceives its environment, chooses actions, and changes that environment through closed-loop interaction.In manipulation settings, state includes the robot, objects, and environmental parameters; digital twins provide controllable, reproducible representations of these elements.Source: §2.1 · pp. 5–6

2.2 Safety Specifications

  • Safety requires applicable predicates to remain satisfied throughout execution, so task completion and execution safety must be evaluated separately.A safety-critical failure occurs when at least one applicable predicate is violated, even if the intended task succeeds.Source: §2.2 · pp. 6–7

2.3 Fault Injection Model

  • EAST’s taxonomy links classes of safety-relevant hazards to evidence-supported executable operators, distinguishing unsafe behaviors from hazardous contexts.Both label types may apply to one execution; operators intervene on targets such as observations, instructions, environment state, actions, or timing.Source: §2.3 · p. 7
  • A fault-injection test specifies a task-policy pair, targeted taxonomy class, supported operator, operator-specific configuration, and reproducibility seeds.The intervention target and configuration must satisfy task-specific applicability and validity checks; the goal is to instantiate a controlled safety challenge and assess the resulting execution.Source: §2.3 · pp. 7–8

3 Methodology

Section 3 presents the design and implementation of EAST.

3 Methodology

  • Section 3 presents the design and implementation of EAST.Source: §3 · p. 8

3.1 Overview of EAST

EAST turns safety knowledge into executable tests through generation, fault-injected digital-twin execution, and simulator-state safety assessment. It fixes specifications before execution and preserves evidence and records for reproducibility.

3.1 Overview of EAST

  • The three-stage workflow generates constrained test specifications, executes them in a digital twin while verifying fault realization, and assesses safety from simulator states and trajectories.The assessment checks predefined safety requirements, while task completion is evaluated independently.Source: §3.1 · p. 8
  • Each reproducible safety-test record links the predefined specification and runtime evidence with challenge exposure, safety outcome, task outcome, and behavior signature.Source: §3.1 · p. 9
  • EAST separates test generation from execution, fixing candidate specifications, configurations, seeds, and test order in advance.Earlier test outcomes do not alter later candidates; saved specifications and ordering allow the planned sequence to be reconstructed and replayed.Source: §3.1 · p. 9

3.2 Stage ❶: Systematic Safety-Test Generation

Stage ❶ turns documented safety hazards into executable fault-injection specifications by grounding operators in evidence and filtering candidates for task-specific applicability, validity, and diversity. Its output is a fixed, traceable execution manifest prepared before outcomes are observed.

3.2.1 Safety-Fault Model Construction.

  • EAST builds its safety-fault model by collecting reported hazards, consolidating recurring patterns into taxonomy classes, and mapping those classes to executable operators.Two experts review evidence-to-category assignments and operator mappings; each class maps to one or more evidence-supported operators.Source: §3.2.1 · pp. 9–10

3.2.2 Applicability and Validity Constraints.

  • Only task–policy, safety-class, and operator combinations passing pre-execution eligibility checks enter the eligible fault-injection space.Checks include runnable task–policy pairs, operator applicability, available safety context, and evidence-supported taxonomy mappings; configuration validity is checked separately.Source: §3.2.2 · pp. 10–11
  • Eight operators cover interventions across the embodied control loop, with operator-specific applicability rules, configuration domains, validity conditions, and runtime evidence.For example, pose shifts must preserve an executable initial scene, while instruction changes must remain syntactically valid and task-interpretable.Source: §3.2.2 · p. 11

3.2.3 Safety-Test-Case Generation and Specification.

  • Candidate generation combines taxonomy guidance and applicability, validity, semantic-preservation, context, deduplication, and diversity checks.Diversity selection uses only pre-execution information, not runtime coverage, observed failures, or safety-oracle outputs.Source: §3.2.3 · p. 12
  • Accepted candidates become machine-readable specifications with provenance, target and realization fields, and a hash identifier, then enter a fixed execution manifest.For a fixed protocol and seed set, the planned sequence is independent of subsequent policy behavior; rejected candidates remain in the generation log.Source: §3.2.3 · p. 12

3.3 Stage ❷: Fault-Injected Digital-Twin Execution

Stage ❷ runs each predefined specification against a policy in the RoboTwin digital twin and verifies that the requested fault was realized. It records execution traces and operator-specific evidence for attribution and replay.

3.3.1 Fault-Injected Digital-Twin Rollout.

  • EAST applies each configured intervention at its specified interface while leaving non-targeted interfaces unchanged.Interventions may occur during scene initialization, between observation and inference, in instruction inputs, between policy output and simulator action, or through recorded action and event relations.Source: §3.3.1 · p. 13

3.3.2 Runtime Realization and Execution Traces.

  • For each specification, EAST records an execution trace and operator-specific evidence, then checks whether that evidence confirms the requested modification.Evidence can include changed image masks, poses, instructions, material states, commands, or event timing.Source: §3.3.2 · p. 13
  • An issued injection command alone does not establish realization; without recorded evidence that the change occurred on the intended target within tolerance, EAST classifies the test as invalid.Exact replay reuses the source specification and all its seeds; stochastic replay changes the policy seed while retaining other settings.Source: §3.3.2 · pp. 13–14

3.4 Stage ❸: Simulator-State Safety Assessment

Stage ❸ uses simulator-state, trajectory, task-outcome, and runtime-realization evidence to assess safety. It separates challenge exposure, task completion, and safety violations, then packages outcomes with behavior signatures for reproducible records.

3.4.1 Safety Oracle and Outcome Classification.

  • The oracle distinguishes whether a realized intervention exposed the policy to the targeted challenge from whether the policy safely defended against it or violated a safety requirement.A policy may terminate or take another path before encountering the state or event needed for challenge exposure.Source: §3.4.1 · p. 14
  • EAST independently evaluates task completion and safety predicates, so ordinary task failure is not automatically a safety failure and a safety violation can be detected despite eventual task success.Missing or invalid required evidence yields INVALID_TEST rather than a negative safety finding; external runtime failures are reported separately.Source: §3.4.1 · pp. 14–15

3.4.2 Behavior Signature and Reproducible Test Record.

  • Each record stores the task outcome, realized injection, challenge and oracle evidence, taxonomy labels, and an observable behavior signature with provenance.Replay outcomes are stored separately from initial outcomes, distinguishing an observed behavior from a later reproducibility check.Source: §3.4.2 · p. 15

4 Experimental Setup

The evaluation addresses safety-fault operationalization, systematic test generation, and comparative effectiveness through six experiments. It specifies the measures, subjects, strategies, and protocols used to assess EAST.

4.2.1 Evaluation Approach.

  • The safety-fault taxonomy was built from published safety evidence, consolidated by failure mechanism and affected component, and independently reviewed by two robotics and software-testing experts.Evidence counted toward a category only when it documented a safety consequence or independently checkable safety condition.Source: §4.2.1 · pp. 16–17

4.2 Evaluation Design

  • Three evaluation designs combine expert-checked taxonomy construction, validity and realization analyses, and matched-budget comparisons with coverage, behavioral-diversity, and replay assessments.Unsafe-success executions are counted separately from testing-effectiveness comparisons.Source: §4.2.1 · p. 17

4.2.2 Evaluation Metrics.

  • The measures distinguish candidate validity, challenge exposure, safety failure, task–policy–operator coverage, behavioral diversity, replay consistency, and unsafe success.A valid test requires verified intervention realization and enough execution and oracle evidence to assess exposure, violations, and task outcome.Source: §4.2.2 · pp. 17–18

4.3 Evaluation Subjects

  • The evaluation used six RoboTwin 2.0 manipulation tasks and ACT and RDT policies, yielding 12 task–policy pairs and 74 admissible task–policy–operator identities.Instruction-level operators applied only to RDT, while the handover-specific operator applied to both policies on Task 1.Source: §4.3 · pp. 18–19

4.4 Compared Strategies

  • EAST was compared with Random-Legal, Rule-Based, and RoboTwin-DR under matched budgets, with Random-Unconstrained used only in Experiment 2 and Clean only in Experiment 3.The component-removal variants were paired ablations rather than external baselines.Source: §4.4 · p. 19

4.5 Experimental Protocol

  • Experiments 1–3 tested operator execution and replay, candidate validity and realization, and equal-budget effectiveness; the latter two used 3,000 records each.Experiment 1 paired 1,600 fault-injected source executions with no-op controls and exact replays, for 4,800 records overall.Source: §4.5 · p. 20
  • Experiments 4–6 characterized taxonomy mappings, compared Full EAST with seven paired component-removal variants, and assessed exact and stochastic replay consistency.Experiment 4 reused existing records; Experiment 5 evaluated eight variants on the same 480 candidates; Experiment 6 selected eight source cases for replay.Source: §4.5 · pp. 20–21

4.6.1 Execution Environment.

  • The experiments retained assigned seeds and settings across workers, while paired-block bootstrap and sign-flip tests quantified uncertainty in matched method comparisons.Statistical procedures varied by experiment, including 10,000 bootstrap resamples for the matched-block comparisons and Holm correction within experiment–metric families.Source: §4.6.2 · p. 21, §4.6.3 · p. 21, §4.6.1 · p. 21

A. Auxiliary analytical attributes

The passages list auxiliary analytical attributes related to evidence and failure characterization.

A. Auxiliary analytical attributes

  • The listed attributes include temporal form, evidence quality, pipeline locus, oracle design, evidence transfer, and failure localization.The passages associate these labels with analytical attribute entries but do not explain their operational definitions.Source: A. Auxiliary analytical attributes · p. 22

X. Explicitly excluded non-safety outcomes

The coding distinguishes non-safety task outcomes as an exclusion from safety evidence.

X. Explicitly excluded non-safety outcomes

  • The evidence table lists “Non-safety Task Outcome” under Exclusion and reports 107/81 total reviewed evidence, with 81 direct-support entries.Source: §X · p. 22

5 Results and Discussion

Across five campaigns, EAST covered all 74 admissible task–policy–operator identities, with challenge-exposure rates close to comparison strategies. The results also distinguish safety violations from task outcomes and show that successful task completion can coexist with a safety breach.

5.1.1 Evidence Synthesis and Validation.

  • Of 107 traceable entries from 15 papers, 81 directly supported the taxonomy; task or robustness failures counted only when independent safety evidence was established.The synthesis mapped 94 entries to Categories 1–7, while retaining auxiliary attributes and excluding non-safety task outcomes.Source: §5.1.1 · pp. 22–23

5.1.2 Safety-Phenotype Structure.

  • Category 7 was a contextual hazard, not a failure type, with 38/81 entries; Categories 2–6 collectively added 30 entries beyond collision-related Category 1’s 13.Attributes preserved temporal-form, evidence-quality, and pipeline-locus information; task failure alone was not safety failure.Source: §5.1.2 · p. 23

5.1.3 From Taxonomy to Executable Operators.

  • Safety categories and operators had many-to-many mappings; Category 2 mapped to six operators, while unsupported category–operator pairs were left unmapped.The mapping required a traceable path from a safety concern to a controllable runtime variable and observable safety-relevant outcome.Source: §5.1.3 · p. 23

5.2.1 Experiment 1: Fault-Injection and Replay Checks.

  • All eight operators achieved 100% VSTY; across 1,600 injected executions, SCER was 76.88% and SFTR was 43.69%, with zero no-op false positives and exact replays matching.The table reports rates for fault-injected source executions; controls and exact replays are additional executions.Source: Table 6 · p. 24, §5.2.1 · pp. 24–25, Table 7 · p. 24

5.2.2 Experiment 2: Candidate Validity and Realization.

  • EAST produced 515/600 valid tests (85.83%) versus 416/600 (69.33%) for Random-Unconstrained, a paired VSTY difference of +16.50 pp, while observed SCER remained similar.EAST’s paired SCER differences were +0.26 pp versus Random-Unconstrained and +2.04 pp versus Random-Legal.Source: Figure 3 · p. 25, §5.2.2 · p. 25, Table 8 · p. 25

5.2.3 Experiment 5: Paired Component Ablation.

  • Validity checking improved VSTY by 20.42 pp, semantic preservation by 13.13 pp, context compatibility by 12.71 pp, and applicability checking by 8.54 pp.Diversity-aware selection instead supported operator breadth and challenge exposure; the ablation describes complementary roles across fidelity and exploration mechanisms.Source: Table 9 · p. 26, §5.2.3 · p. 26

5.3.1 Experiment 3: Equal-Budget Comparative Safety Testing.

  • Across five campaigns, EAST covered all 74 admissible identities and had 76.12% SCER versus 74.73% Random-Legal and 73.83% Rule-Based; 82 EAST executions succeeded unsafely.The 74 identities had valid evidence for 63 in each campaign; the unsafe-success counts characterize divergence between task and safety evaluation, not method superiority.Source: Table 10 · p. 27, §5.3.1 · p. 27, §5.3.3 · p. 29
  • EAST reached all 74 targeted identities and 63 valid identities per campaign, while exposing 27 distinct safety-failure signatures versus 39 for Random-Legal and 8 for Rule-Based.Cumulative curves show discoveries over test order; signature diversity and intervention-space coverage capture different aspects of effectiveness.Source: §5.3.1 · pp. 27–28, Figure 4 · p. 27

6 Threats to Validity

The section assesses construct, internal, external, and conclusion validity, describing safeguards and boundaries for interpreting EAST’s evidence.

6.1 Construct Validity

  • Safety-critical failures are defined through simulator-observable safety predicates, excluding hazards requiring unmodeled physical quantities, long-term effects, or normative judgments.The operationalization separates safety outcomes from task outcomes and includes context-dependent hazards in Category 7.Source: §6.1 · p. 31
  • VSTY, SCER, and SFTR measure distinct testing stages; challenge exposure, violations, task–safety divergence, validity, coverage, diversity, and replay are reported separately.High challenge exposure does not establish a safety violation, and unsafe-success diagnoses outcome divergence rather than method superiority.Source: §6.1 · p. 31

6.2 Internal Validity

  • Fixed task and policy configurations, matched seeds, control executions, and recorded candidate sources and runtime evidence address implementation and execution threats.Experiment 5 matched underlying unfiltered candidates and prescribed random seeds between Full EAST and its ablated version.Source: §6.2 · p. 31

6.3 External Validity

  • The empirical scope covers six RoboTwin 2.0 manipulation tasks and ACT and RDT; broader robot, hardware, task, and policy coverage remains future work.Physical-hardware transfer is a separate validation dimension because contact forces, sensing, controller timing, and failure consequences can differ from simulation [7] [44] [56].Source: §6.3 · p. 32

6.4 Conclusion Validity

  • Experiments use experiment-specific comparison units and denominators; category counts may overlap because one record can contribute to multiple categories.Experiments 2 and 3 compare task–policy–campaign blocks, while Experiment 5 uses matched unfiltered candidates for component-level attribution.Source: §6.4 · p. 32

7 Related Work

Related work spans embodied-AI evaluation, robustness testing, and software-testing techniques. EAST connects safety evidence to constrained test generation, verified runtime interventions, and replayable outcomes.

7.1 Embodied AI Evaluation

  • Task-oriented benchmarks assess completion and generalization, while safety-oriented studies add hazardous contexts and safety metrics; EAST links fault models to validity-constrained tests and replayable evidence.The related work discusses embodied benchmarks and safety-oriented evaluations, including RLBench, CALVIN, ManiSkill2, RoboTwin, Safety Gym, and ForesightSafety-VLA.Source: §7.1 · pp. 32–33

7.2 Robustness Testing for Embodied AI

  • Robustness approaches vary environments, perception, or dynamics, but generally lack explicit safety-fault models and systematic generation of targeted fault scenarios.Prior approaches emphasize performance degradation or generalization under predefined variations.Source: §7.2 · p. 33

7.3 Software Testing Techniques for AI Systems

  • Software testing includes fault modeling, injection, mutation, fuzzing, and automated generation; EAST focuses on traceable links between safety evidence, operator applicability, fault realization, and outcomes.Prior work spans component-level neural-network testing as well as robotic fuzzing and temporal falsification of system-level executions.Source: §7.3 · pp. 33–34

8 Conclusions and Future Work

EAST combines fault-model-based generation, runtime verification, and simulator-state safety assessment in digital twins. Across six manipulation tasks and two policy families, it covers more admissible combinations, while task completion can coexist with safety violations.

8 Conclusions and Future Work

  • EAST’s three stages generate executable fault-injection specifications, verify runtime realization and record traces, then assess challenge exposure, violations, task outcomes, and behavior signatures.The framework uses a literature-grounded fault model, eight runtime operators, applicability and executability checks, simulator-state oracles, and reproducible test records.Source: §8 · p. 34
  • EAST covered a larger set of admissible task–policy–operator combinations, with challenge-exposure rates close to Random-Legal and Rule-Based; task completion could coexist with safety violations.The authors conclude that task success and raw failure counts alone are insufficient, recommending consideration of validity, exposure, coverage, diversity, and reproducibility.Source: §8 · p. 34
  • Future work will extend the taxonomy and operators across platforms and tasks, compare digital twins with controlled physical-robot experiments, and add richer temporal and contextual predicates.Proposed predicates could capture hazards involving longer execution histories, human proximity, or task-specific operating constraints.Source: §8 · pp. 34–35
Loading 2610.34358v1…