eae-performance-analyzer（EAE 性能分析仪）

EAE Performance Analyzer - Event Storm Prevention

Prevents catastrophic event storms in EcoStruxure Automation Expert applications through comprehensive static analysis. Identifies cascading event patterns, predicts queue overflow, estimates CPU load, and detects anti-patterns before deployment.

Critical Problem: Event storms cause Error Halt states, event loss, I/O glitches, and cross-communication failures in production EAE systems. Current detection is reactive (runtime monitoring) rather than proactive (design validation).

Solution: Multi-dimensional static analysis at design time calculates event multiplication factors, predicts queue depths, estimates CPU utilization, and flags explosive patterns with actionable recommendations.

Quick Start

Analyze entire application:

Analyze my EAE application for event storm risks

Analyze specific resource:

Check Resource1 in my EAE application for performance issues

Generate visual event flow diagram:

Analyze my EAE application and show me the event flow visualization

Triggers

This skill activates on:

• "Analyze my EAE application for event storms"
• "Check for performance issues in my EAE project"
• "Detect event cascade problems in EcoStruxure Automation Expert"
• "Validate event flow before deployment"
• "Predict event storm risks"

Quick Reference

How It Works

4-Dimensional Analysis

The skill performs parallel analysis across 4 independent dimensions:

Parse EAE Application (.fbt, .cfg, .xml)
    │
    ├─→ [Event Flow Analysis] → Multiplication factors, cascade paths
    ├─→ [CPU Load Estimation] → Algorithm complexity, execution time
    ├─→ [Queue Depth Prediction] → External/internal queue modeling
    └─→ [Pattern Detection] → Known storm anti-patterns
    │
    ▼
Synthesis → Integrated risk assessment + recommendations
    │
    ▼
Reports (JSON, Markdown, Graphviz) + Deployment decision

Event Multiplication Factor (Primary Metric)

The event multiplication factor quantifies how many downstream events result from a single event source:

• 1.0x: No multiplication (1 event → 1 event) - Ideal
• 5.0x: Low multiplication (1 event → 5 events) - Safe
• 15.0x: Moderate multiplication - Monitor
• 30.0x: High multiplication - Warning
• 50.0x+: Explosive multiplication - Critical storm risk

Example: An I/O change event triggers 3 FBs, each generating 2 output events that trigger 4 more FBs → 1 event becomes 26+ events (26x multiplication).

Commands

Basic Analysis

# Analyze entire application
Analyze c:/Projects/MyEAEApp for event storm risks

# Analyze with custom output location
Analyze c:/Projects/MyEAEApp and save report to c:/Reports/performance.md

Resource-Specific Analysis

# Analyze single resource (faster iteration)
Analyze Resource_PLC1 in c:/Projects/MyEAEApp

# Compare multiple resources
Analyze c:/Projects/MyEAEApp and compare performance across resources

Advanced Options

# Include event flow visualization
Analyze c:/Projects/MyEAEApp with event flow diagram

# Specify target platform for calibrated thresholds
Analyze c:/Projects/MyEAEApp for soft-dpac platform

# Custom load scenario
Analyze c:/Projects/MyEAEApp under worst-case load scenario

Scripts

This skill includes 4 autonomous Python scripts for fully agentic operation:

1. analyze_event_flow.py - Event Cascade Analysis

Purpose: Traces event propagation through FBNetworks, calculates multiplication factors, identifies explosive patterns.

Usage:

python scripts/analyze_event_flow.py --app-dir c:/Projects/MyEAEApp --output results.json
python scripts/analyze_event_flow.py --app-dir c:/Projects/MyEAEApp --visualize --output flow.dot
python scripts/analyze_event_flow.py --app-dir c:/Projects/MyEAEApp --resource Resource1

Exit Codes:

• 0: No issues (multiplication <10x)
• 10: Moderate risk (10-20x multiplication)
• 11: High risk (>20x multiplication)
• 1: Error (parsing failure, invalid files)

Output: JSON with multiplication factors, cascade paths, explosive patterns, resource breakdown

2. estimate_cpu_load.py - CPU Utilization Analysis

Purpose: Analyzes ST algorithm complexity, estimates execution time, aggregates resource CPU load.

Usage:

python scripts/estimate_cpu_load.py --app-dir c:/Projects/MyEAEApp --output cpu_load.json
python scripts/estimate_cpu_load.py --app-dir c:/Projects/MyEAEApp --platform hard-dpac-m262
python scripts/estimate_cpu_load.py --app-dir c:/Projects/MyEAEApp --resource Resource1

Exit Codes:

• 0: Low load (<70%)
• 10: Moderate load (70-90%)
• 11: High load (>90%)
• 1: Error (parsing failure)

Output: JSON with per-FB execution estimates, per-resource CPU load percentages, bottleneck identification

Note: Execution time estimates are approximate (±50% margin) due to platform variance and compiler optimizations.

3. predict_queue_depth.py - Queue Overflow Prediction

Purpose: Models event queue behavior, predicts peak depths under various load scenarios.

Usage:

python scripts/predict_queue_depth.py --app-dir c:/Projects/MyEAEApp --event-flow-results results.json
python scripts/predict_queue_depth.py --app-dir c:/Projects/MyEAEApp --event-flow-results results.json --scenario worst-case
python scripts/predict_queue_depth.py --app-dir c:/Projects/MyEAEApp --event-flow-results results.json --resource Resource1

Exit Codes:

• 0: Safe (<100 events)
• 10: Moderate (100-500 events)
• 11: Overflow risk (>500 events)
• 1: Error (missing dependencies)

Output: JSON with queue depth predictions (normal/burst/worst-case), event source contributions, overflow warnings

Requires: Output from analyze_event_flow.py (JSON file path via --event-flow-results)

4. detect_storm_patterns.py - Anti-Pattern Detection

Purpose: Rule-based detection of known event storm anti-patterns from SE Application Design Guidelines.

Usage:

python scripts/detect_storm_patterns.py --app-dir c:/Projects/MyEAEApp --output patterns.json

Exit Codes:

• 0: No anti-patterns
• 10: Minor anti-patterns (INFO/WARNING)
• 11: Severe anti-patterns (CRITICAL)
• 1: Error (parsing failure)

Output: JSON with detected patterns, severity levels, source locations, pattern-specific recommendations

Detected Anti-Patterns:

• TIGHT_EVENT_LOOP (CRITICAL): Event loops back to source within 2 hops
• UNCONTROLLED_IO_MULTIPLICATION (WARNING): Single I/O event triggers >30 events
• CASCADING_TIMERS (WARNING): Multiple fast timers on same resource
• HMI_BURST_AMPLIFICATION (INFO): HMI events trigger >10 downstream events
• CROSS_RESOURCE_AMPLIFICATION (WARNING): Cross-resource events trigger >15 events

Validation

Pre-Analysis Validation

Before analysis begins:

• ✅ Verify EAE application directory exists and contains .fbt/.cfg/.xml files
• ✅ Parse all XML files for well-formedness
• ✅ Resolve all FB references (check for missing library FBs)
• ✅ Validate resource mappings (FBs assigned to valid resources)

Analysis Validation

During analysis:

• ✅ Event multiplication factor ≥0 (sanity check)
• ✅ Queue depth predictions ≥0 (sanity check)
• ✅ CPU load estimates 0-100% (sanity check)
• ✅ All cascade paths terminate (no infinite loops in graph traversal)

Post-Analysis Validation

After synthesis:

• ✅ Every WARNING/CRITICAL issue has at least one recommendation
• ✅ Overall risk assessment matches worst individual dimension
• ✅ Deployment recommendation justified by specific metrics
• ✅ All requested output formats generated successfully

Anti-Patterns

Verification Criteria

After running analysis, verify:

• [ ] Analysis completed in <2 minutes for large applications (1000+ FBs)
• [ ] All 4 scripts returned exit codes 0, 10, or 11 (not 1=error)
• [ ] JSON reports parse successfully and contain expected fields
• [ ] Multiplication factors are numeric and ≥0
• [ ] Queue depth predictions are numeric and ≥0
• [ ] CPU load estimates are 0-100%
• [ ] Every WARNING/CRITICAL issue has recommendation
• [ ] Overall risk level matches worst individual dimension
• [ ] Deployment recommendation is one of: SAFE TO DEPLOY, DEPLOY WITH CAUTION, DO NOT DEPLOY
• [ ] If event flow visualization requested, .dot file generated

Integration with EAE Skills

<details> <summary><strong>Deep Dive: Event Multiplication Analysis</strong></summary>

Event Multiplication Mechanics

IEC 61499 Execution Model

EAE follows the IEC 61499 event-driven execution model with dual queues per resource:

1. External Queue: Events from outside the resource (I/O, HMI, cross-communication) - FIFO
2. Internal Queue: Events generated by FBs within the resource

Critical Processing Order:

1. Pop event from external queue
2. Execute target FB
3. FB generates output events → pushed to internal queue
4. Process ALL internal events until queue empty (cascade completes)
5. Return to step 1 (next external event)

Storm Trigger: If step 4 generates more events than step 1 consumes, queues grow unbounded.

Multiplication Factor Calculation

For each event source S:

Multiplication Factor = Total Events Generated / 1 Event from S

Example:
  I/O Change Event "DI_Start"
    → Triggers ControllerFB (generates 2 events)
      → Each triggers 2 ProcessFBs (4 events total)
        → Each triggers LoggerFB (4 events total)

  Total: 1 + 2 + 4 + 4 = 11 events
  Multiplication Factor: 11 / 1 = 11.0x

Event Sources Modeled

Cascade Path Tracing

The script uses Breadth-First Search (BFS) to enumerate all paths from event source to leaf FBs:

Source: INIT event on MainFB
  Path 1: MainFB → ProcessFB1 → LoggerFB (3 hops, 3 events)
  Path 2: MainFB → ProcessFB2 → AlarmFB (3 hops, 3 events)
  Path 3: MainFB → ProcessFB2 → TrendFB (3 hops, 3 events)

  Multiplication: 9 events / 1 source = 9.0x

Paths are color-coded in visualizations:

• Green: <10x (safe)
• Yellow: 10-20x (caution)
• Red: 20-50x (warning)
• Dark Red: >50x (critical)

</details>

<details> <summary><strong>Deep Dive: CPU Load Estimation</strong></summary>

Algorithm Complexity Analysis

ST Code Metrics

The script analyzes Structured Text (ST) algorithms using simplified metrics:

Formula:

Execution Time ≈ (Complexity × 10μs) + (Operations × 1μs) + (DataAccess × 0.5μs)

Platform Factors:

• Soft dPAC (Windows): 1.0x baseline
• Soft dPAC (Linux): 0.9x (slightly faster)
• Hard dPAC M251: 1.5x (slower embedded CPU)
• Hard dPAC M262: 1.2x (faster embedded CPU)

Limitations

IMPORTANT: Execution time estimates are heuristic-based and vary ±50% due to:

• Compiler optimizations (loop unrolling, inlining)
• Cache effects (data locality, cache hits/misses)
• Operating system scheduling (preemption, interrupts)
• Instruction-level parallelism (CPU pipelining)
• Platform-specific instruction sets (SSE, AVX on x86)

Treat estimates as order-of-magnitude indicators: 50μs vs 500μs vs 5ms, not precise timings.

Resource CPU Load Aggregation

For each resource:

CPU Load % = (Σ FB Execution Times × Event Frequency) / Available CPU Time × 100

Example Resource1:
  FB1: 100μs × 10 Hz (I/O events) = 1000μs/s = 0.1% load
  FB2: 500μs × 100 Hz (timer events) = 50000μs/s = 5.0% load
  FB3: 200μs × 5 Hz (HMI events) = 1000μs/s = 0.1% load

  Total: 5.2% load
  Headroom: 94.8%

Thresholds:

• <70%: SAFE (ample headroom)
• 70-90%: CAUTION (monitor under load)
• 90-95%: WARNING (minimal headroom)
• >95%: CRITICAL (insufficient headroom for bursts)

</details>

<details> <summary><strong>Deep Dive: Queue Depth Prediction</strong></summary>

Queue Behavior Modeling

Dual Queue System

Each EAE resource maintains two event queues:

External Queue (from outside resource)
  ← I/O events
  ← HMI events
  ← Cross-communication events
  ← Timer events (E_CYCLE)

Internal Queue (from FBs in resource)
  ← FB output events
  ← Algorithm-generated events
  ← Cascaded events

Processing: External queue feeds internal queue, internal queue processes until empty before next external event.

Load Scenarios

Prediction Formula

Peak Queue Depth = (Event Generation Rate × Burst Duration) - (Processing Rate × Burst Duration)

If Peak Depth > Threshold:
  Overflow Risk = HIGH

Example:

Normal:
  Generation: 100 events/s
  Processing: 200 events/s
  Queue Depth: 0 (steady state)

Burst:
  Generation: 200 events/s (2× normal)
  Processing: 200 events/s
  Queue Depth: 0 (just keeping up)

Worst-Case:
  Generation: 500 events/s (5× normal, all aligned)
  Processing: 200 events/s
  Queue Depth: (500 - 200) × 5s = 1500 events (OVERFLOW)

Event Source Contributions

The report breaks down which sources contribute most to queue load:

{
  "event_sources_contribution": {
    "IO_CHANGE": "35%",
    "HMI_INTERACTION": "25%",
    "TIMERS": "20%",
    "CROSS_COMMUNICATION": "15%",
    "INTERNAL_LOGIC": "5%"
  }
}

This identifies where to focus optimization efforts (e.g., "Reduce timer frequency" vs "Consolidate HMI events").

</details>

<details> <summary><strong>Deep Dive: Anti-Pattern Detection</strong></summary>

Known Storm Patterns

Based on SE Application Design Guidelines (EIO0000004686.06):

1. TIGHT_EVENT_LOOP (CRITICAL)

Description: FB event output connects back to its own input within 2 hops, creating unstoppable cascade.

Detection: Graph cycle detection with depth limit 2.

Example:

ControllerFB.Output_Event
  → ProcessFB.Input_Event
    → ProcessFB.Output_Event
      → ControllerFB.Input_Event  ← LOOP DETECTED

Risk: Infinite event generation until Error Halt.

Recommendation: Break loop with state guard (flag variable) or timer-based debouncing.

2. UNCONTROLLED_IO_MULTIPLICATION (WARNING)

Description: Single I/O change triggers >30 downstream events (common with broadcast patterns).

Detection: Event cascade tracing from I/O sources, count total events.

Example:

DI_Emergency_Stop changes
  → Triggers SafetyControllerFB (5 events)
    → Each triggers AlarmFB + LoggerFB + HMIFB (3 × 5 = 15 events)
      → Each triggers NotificationFB (15 events)

  Total: 1 + 5 + 15 + 15 = 36 events (>30 threshold)

Risk: I/O events are frequent (10-100ms cycle) - high multiplication causes saturation.

Recommendation: Consolidate responses using adapter pattern or EventChainHead FB (SE.AppSequence library).

3. CASCADING_TIMERS (WARNING)

Description: Multiple fast timers (E_CYCLE <50ms) on same resource sum to high frequency baseline load.

Detection: Sum all timer frequencies per resource, flag if >100Hz aggregate.

Example:

Resource1:
  Timer1: E_CYCLE at 20ms (50 Hz)
  Timer2: E_CYCLE at 30ms (33 Hz)
  Timer3: E_CYCLE at 40ms (25 Hz)

  Total: 50 + 33 + 25 = 108 Hz (>100 Hz threshold)

Risk: Constant event load leaves no headroom for I/O or HMI events.

Recommendation: Reduce timer frequencies, consolidate timers, or distribute across resources.

4. HMI_BURST_AMPLIFICATION (INFO)

Description: HMI operator actions trigger >10 downstream events (normal but can spike under rapid interaction).

Detection: Trace HMI event sources (IThis interface events), count cascade.

Example:

HMI Setpoint Change
  → ControllerFB validates (2 events)
    → ProcessFB updates (3 events)
      → TrendFB logs (3 events)
        → AlarmFB checks limits (2 events)

  Total: 1 + 2 + 3 + 3 + 2 = 11 events (>10 threshold)

Risk: Rapid operator interactions (button mashing) create bursts.

Recommendation: Add debouncing (e.g., 100ms delay) or rate limiting on HMI inputs.

5. CROSS_RESOURCE_AMPLIFICATION (WARNING)

Description: Event crossing resource boundary (via OPC-UA/networking) triggers >15 events on target resource.

Detection: Identify cross-resource connections, trace cascade on target resource.

Example:

Resource1.OutputEvent
  → [Network: 10-100ms latency]
    → Resource2.InputEvent
      → Triggers 18 events on Resource2 (>15 threshold)

Risk: Network latency + event multiplication can cause target resource saturation.

Recommendation: Reduce cross-resource event frequency, consolidate with adapters, or use EventChainHead.

</details>

<details> <summary><strong>Deep Dive: Actionable Recommendations</strong></summary>

Recommendation Patterns

For each identified issue, the skill provides specific, implementable fixes:

Event Consolidation Pattern

Problem: High event multiplication (20-50x)

Recommendation:

Use EventChainHead (SE.AppSequence library) to consolidate cascading events:

1. Create EventChainHead FB instance
2. Connect all event sources to EventChainHead.Input[]
3. EventChainHead outputs single CONSOLIDATED event
4. Connect CONSOLIDATED to downstream FBs

Reduction: 50x → 5x (10:1 improvement)

Before:

Event → FB1 → FB2 → FB3 → FB4 → FB5 (5 events)
     ↘ FB6 → FB7 → FB8 → FB9 → FB10 (5 events)
     ↘ ... (repeat 5× = 50 events total)

After:

Event → EventChainHead → CONSOLIDATED → (all FBs receive 1 event)

Adapter Encapsulation Pattern

Problem: Uncontrolled I/O multiplication (>30 events)

Recommendation:

Encapsulate related I/O responses in Composite FB with adapter interface:

1. Create Composite FB "SafetyResponseController"
2. Add adapter input (Socket) for I/O event
3. Implement response logic inside Composite (hidden complexity)
4. Export single adapter output (Plug) with consolidated result
5. Connect I/O to adapter Socket

Reduction: 36 events → 3 events (adapter input + internal + adapter output)

Benefit: I/O sees simple 1:1 connection, complexity hidden inside Composite.

Timer Frequency Reduction Pattern

Problem: Cascading timers (>100Hz aggregate)

Recommendation:

Reduce non-critical timer frequencies:

Identify timers by criticality:
- Safety/control loops: Keep fast (10-50ms)
- Trending/logging: Slow to 100-500ms
- Heartbeats: Slow to 1000ms

Example:
  TrendFB timer: 20ms → 200ms (50 Hz → 5 Hz)
  Savings: 45 Hz per resource

Impact: 108 Hz → 63 Hz (below 100 Hz threshold)

Resource Distribution Pattern

Problem: Single resource overloaded (CPU >90% or queue >500)

Recommendation:

Distribute FBs across multiple resources:

1. Identify high-load FBs (top 20% by CPU)
2. Move to dedicated resource (Resource2)
3. Use adapters for cross-resource communication
4. Update resource mappings in .cfg

Example:
  Resource1: 95% load → 65% load (30% moved)
  Resource2: 0% load → 30% load (receives moved FBs)

Consideration: Cross-resource events have 10-100ms latency - ensure control loops stay on same resource.

Loop Breaking Pattern

Problem: Tight event loop (CRITICAL)

Recommendation:

Break loop with state guard:

1. Add BOOL internal variable "m_EventProcessed"
2. In algorithm that generates loop event:

   IF NOT m_EventProcessed THEN
     m_EventProcessed := TRUE;
     // Generate output event
   END_IF

3. Reset flag on different event path

Alternative: Use timer-based debouncing (100ms minimum between events)

Result: Loop executes once per trigger instead of infinitely.

</details>

Extension Points

Future enhancements planned:

1. Simulation-Based Analysis (Year 2)

- Execute application with synthetic event sources - Measure actual queue depths and CPU load - Complement static analysis with dynamic verification

1. Historical Trend Analysis (Year 1)

- Track performance metrics over application versions - Identify regressions (e.g., "v2.1 added 15x multiplication") - CI/CD integration for automated tracking

1. Platform-Specific Calibration (Year 1)

- Empirical calibration of CPU thresholds per platform - Database of platform profiles (Soft dPAC, M251, M262) - Improved execution time accuracy

1. Auto-Refactoring Suggestions (Year 2+)

- Generate actual code changes (insert EventChainHead, create adapters) - One-click fixes for common patterns - Requires deep code generation capability

1. Multi-Application Analysis (Year 2+)

- Analyze multiple applications sharing same dPAC - Aggregate load across multi-tenant scenarios - Total system capacity planning

References

• SE Application Design Guidelines (EIO0000004686.06) - Official SE documentation on event storms and performance
• EAE Concepts Primer - IEC 61499 fundamentals
• Event Storm Patterns - Detailed anti-pattern catalog
• Performance Thresholds - Threshold calibration rationale
• Script Implementation Details - Algorithm details for scripts

Related Skills

Changelog

v1.0.0 (2026-01-20)

• Initial release
• 4-dimensional analysis (event flow, CPU load, queue depth, anti-patterns)
• 4 autonomous Python scripts with full agentic capabilities
• Multi-format reporting (JSON, Markdown, Graphviz)
• Integration with existing EAE skill ecosystem
• Timelessness score: 9/10 (based on IEC 61499 fundamentals)