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

Analysis Dimension Metric Safe Threshold Warning Threshold Critical Threshold

Event Multiplication Single event → N events <10x 10-20x

20x

Queue Depth Peak events in queue <100 100-500

500

CPU Load Resource utilization % <70% 70-90%

90%

Anti-Patterns Detected issues 0 Minor patterns Severe patterns

Risk Level Deployment Recommendation Typical Action

SAFE Deploy with confidence No action needed

CAUTION Review before deployment Optional optimization

WARNING Deploy with monitoring Address high-priority issues

CRITICAL Do not deploy Fix severe issues first

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

Avoid Why Instead

Runtime-only monitoring Too late - storms discovered in production cause downtime Static analysis at design time

Single-metric focus (CPU only) Event storms are multi-dimensional 4-dimensional analysis (events, CPU, queues, patterns)

Blocking deployment without override Tool has false positives, engineer judgment paramount Recommend but allow override with confirmation

Perfect accuracy claims Algorithm timing is approximate due to platform variance Communicate uncertainty (±50% margin)

Ignoring resource boundaries Distributed apps have different characteristics Per-resource analysis + cross-resource modeling

Raw metrics without fixes Engineers need "how to fix" not just "what's wrong" Every issue includes actionable recommendation

Slow, complex analysis Won't be used in iterative workflow Fast (<2 min), minimal setup

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

Skill Integration Point How Performance Analyzer Helps

eae-basic-fb After Basic FB creation Analyzes event generation patterns, warns if high multiplication potential

eae-composite-fb After Composite FB creation Checks FBNetwork complexity, identifies cascade risks

eae-cat After CAT creation Validates cross-communication patterns, HMI event loads

eae-adapter After adapter creation Analyzes bidirectional event flow impact

eae-skill-router Orchestration Automatically suggests performance analysis after artifact creation

Event Multiplication Mechanics

IEC 61499 Execution Model

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

• External Queue: Events from outside the resource (I/O, HMI, cross-communication) - FIFO

• Internal Queue: Events generated by FBs within the resource

Critical Processing Order:

• Pop event from external queue

• Execute target FB

• FB generates output events → pushed to internal queue

• Process ALL internal events until queue empty (cascade completes)

• 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

Source Type Frequency Characteristics

I/O Changes Bus cycle dependent (10-100ms) State-driven, bursty

HMI Interactions Operator-driven (1-10 Hz) Unpredictable, can burst

Timers (E_CYCLE) Fixed (1ms - 1s) Constant, predictable

Cross-Communication Application-driven Network latency (10-100ms)

Internal Logic Event-driven cascade Multiplication dependent

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)

Algorithm Complexity Analysis

ST Code Metrics

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

Metric Description Weight

Cyclomatic Complexity Branches (IF/CASE) + Loops (FOR/WHILE) + 1 High impact

Operation Count Arithmetic, logic, function calls Medium impact

Data Access Variable reads/writes, array indexing Low impact

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)

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

Scenario Description Event Rates

Normal Average operating conditions 1× baseline rates

Burst Operator interaction spike 2× baseline rates, 5s duration

Worst-Case All sources simultaneous + timers aligned 5× baseline rates, all timers fire together

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").

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.

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.

Extension Points

Future enhancements planned:

Simulation-Based Analysis (Year 2)

• Execute application with synthetic event sources

• Measure actual queue depths and CPU load

• Complement static analysis with dynamic verification

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

Platform-Specific Calibration (Year 1)

• Empirical calibration of CPU thresholds per platform

• Database of platform profiles (Soft dPAC, M251, M262)

• Improved execution time accuracy

Auto-Refactoring Suggestions (Year 2+)

• Generate actual code changes (insert EventChainHead, create adapters)

• One-click fixes for common patterns

• Requires deep code generation capability

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

Skill Relationship

eae-basic-fb Analyzed by this skill (event generation patterns)

eae-composite-fb Analyzed by this skill (network complexity)

eae-cat Analyzed by this skill (cross-communication patterns)

eae-adapter Analyzed by this skill (bidirectional event flow)

eae-skill-router Orchestrates this skill after artifact creation

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)