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)

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)

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

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.