Troubleshooting SIMOTION D445 F360:BE02 Sign-of-Life Failure

Troubleshooting SIMOTION D445 F360:BE02 Sign-of-Life Failure on Sinamics SM150 Drives

When a SIMOTION D445 controller drops a Sinamics SM150 main drive into STOP mode while the hot strip mill is rolling, the first diagnostic buffer entry usually tells the story. In a representative plant incident, event ID 16# F360:BE02 appeared with additional information 16# C4 50 and 16# 0003 0000 0009, accompanied by the explanation text: "STOP by execution system, cause: Timeout BackgroundTask". The same event, raised on the slave processor of the integrated SINAMICS control, is the classic signature of a sign-of-life failure cascading into a controlled STOP transition.

This field-proven reference walks through decoding the diagnostic buffer, identifying the root cause, isolating user code from firmware faults, and restoring the drive without a hot strip mill scrap event.

1. Problem Definition and Operational Impact

The fault surface is deceptively simple:

• SIMOTION D445 controller hosting the Sinamics SM150 drive control for a hot strip mill stand (coiler, roughing mill, or finishing mill).
• Drive transitions from RUN to STOP mode mid-rolling.
• Diagnostic buffer opens with the message "Sign-of-life failure of the slave processor: 2" followed by "STOP by execution system, cause: Timeout BackgroundTask".
• Event timestamp: 20:56:33.868 (entry 39 of 609 logged entries in the example).
• No preceding SINAMICS F-fault (e.g. F30002 overcurrent, F07900 overspeed). The STOP is generated by the SIMOTION execution system, not by the drive power section.

2. SIMOTION D445 Architecture and the Slave Processor

The SIMOTION D445 is a SIMOTION controller with an integrated SINAMICS S120 control unit. It is frequently paired with a Sinamics SM150 (the LV/MV version of the SINAMICS family used for main drives from 1 MW to 30+ MW) in rolling mill applications. Three processor domains cooperate inside the D445:

The "sign-of-life" mechanism is a hardware-tied cyclic counter incremented on the slave and polled by the SIMOTION master. If the counter stops incrementing for a configurable number of cycles, the master raises F360:BE02 and issues a STOP to the technology objects. This is a fail-safe: an unmonitored slave could feed stale setpoints into a 5,000 kW drive.

3. Decoding Diagnostic Buffer Event F360:BE02

The diagnostic buffer in SIMOTION SCOUT (Device → Diagnostics → Diagnostic buffer) shows the event in a fixed format. The example is broken down below.

3.1 Cause Code Reference (SIMOTION Execution System)

4. Root Cause Analysis — Why the Slave Stops Responding

In SIMOTION D4x5 hardware, "sign-of-life failure of the slave processor: 2" with cause 0xC450 has a small set of recurring triggers. The first three are software-induced and recoverable; the last two are hardware- or firmware-induced.

4.1 Runaway Loop in a User BackgroundTask (most common)

The BackgroundTask is the lowest-priority task in the SIMOTION execution system. It is normally configured to a 10–100 ms cycle and is the recommended home for non-deterministic logic: HMI data marshaling, file I/O via _fileSystem, archive flush, OPC UA server housekeeping, and slow arithmetic. If the BackgroundTask does not finish before the next scheduling point, the execution system flags a timeout.

Common runaway-loop patterns reported in field logs:

• WHILE ... DO in MCC or ST with no exit condition that depends on an external signal that never arrives.
• Polling a BOOL input using _getBit without any cyclic decrement of a counter that breaks the loop.
• Synchronous PRINT to Output Window of SIMOTION SCOUT online at high frequency. Online I/O is blocking; the BackgroundTask will not preempt a serial write to the engineering port.
• Calling _readRecord/_writeRecord against a PROFIBUS DP slave that is in failure mode — the function blocks until a watchdog elapses.
• Calling a user-defined function block from BackgroundTask that internally invokes _waitTime with a value exceeding the task cycle.

4.2 Drive Control Chart (DCC) Block Saturating the Slave

The slave processor runs DCC for closed-loop functions that are CPU-expensive. A DCC scheme that has grown through the years (additional blocks added for diagnostics, neural-network auto-tuning, or extra adaptive controllers) can exceed the per-cycle budget. When the slave misses its deadline, the master flags the sign-of-life loss. Typical duration observed: 2–10 minutes of growing DCC runtime until the fault trips.

4.3 Cross-CU Communication Saturation (CU-Link to SM150)

SM150 drives often run on a separate Control Unit connected to the D445 via CU-Link or DRIVE-CLiQ. Burst PROFIsafe or PROFINET traffic on the same CPU can starve the link buffer. The slave processor polls the link, finds no response, and the master declares a sign-of-life failure.

4.4 SD Card / CFast File-System Hang

D445 retains user data and archives on a SIMOTION CFast card. A failing card or a full partition causes _fileSystem calls to block indefinitely. BackgroundTask hangs and the 0xC450 timeout is raised.

4.5 Firmware Defect (rare but documented)

Siemens has acknowledged firmware-internal issues that surface as 0xC450 with the same additional info pattern, particularly around SIMOTION V4.4 SPx and V5.x on D445 with extensive DCC charts. The standard recommendation is to upload the diagnostic buffer to Siemens Industry Online Support and open a support request referencing the F360:BE02 event and the firmware version on the type plate of the D445 (visible on the unit's FW line in SCOUT under Target system → Version view).

5. Prerequisites for Diagnosis

• SIMOTION SCOUT TIA or SCOUT Standalone V5.x, project consistent with the device firmware.
• Online connection to the D445 (PROFINET, PROFIBUS, or Ethernet service port).
• Read access to the diagnostic buffer and the task trace.
• For DCC analysis: SIMOTION DCC editor + SINAMICS DCC V15 or higher.
• Source archive (SCOUT → Project → Archive) for offline analysis of MCC/ST sources.
• CFast card reader if the card is to be imaged.
• Stop-permit from operations — many of the steps below require a controlled ramp-down of the stand.

6. Step-by-Step Diagnostic Procedure

1. Capture the diagnostic buffer. In SCOUT, open the D445 target → Diagnostics → Diagnostic buffer. Export the complete buffer (right-click → Export). Note entries ± 30 around the F360:BE02 event, including the times of the previous BackgroundTask completion.
2. Decode the additional information. Use Table 2 above. Confirm 0xC4 50 in additional info 4/5. If the value is different, jump to the matching cause in Table 3.
3. Open the task trace. In SCOUT, Target system → Task Trace. Filter to the BackgroundTask row and look at the maximum execution time column. Compare against the configured cycle time. A max execution time > 70% of the cycle time is the leading indicator of an imminent timeout.
4. Examine the BackgroundTask configuration. Open Execution system → Tasks → BackgroundTask in the project navigator. Note the cycle time and the priority (default: 8). Cross-check with the user's MCC/ST source for that task.
5. Static review of BackgroundTask source. Search the MCC chart or ST source for the patterns in §4.1. In ST, look for any WHILE, REPEAT, _waitTime, _readRecord, _writeRecord, PRINT, or function-block calls to _fileSystem. In MCC, look for Loop until blocks where the exit condition is a tag that is only ever set from the same loop.
6. Profile DCC runtime. In the SINAMICS drive unit, open Commissioning → DCC → Runtime measurement. Compare the slave processor load against the 80% warning threshold. If the load is climbing across the trend, the runaway is in DCC, not in the user ST.
7. Check DRIVE-CLiQ / CU-Link topology. In SCOUT, Target system → Topology. Look for CRC errors, lost frames, or any slave in degraded state. If the SM150 CU shows intermittent outages, the cause is §4.3.
8. Inspect the CFast card. In offline mode, mount the card image in a Linux VM and run dosfsck -v /dev/sdX1. Look for FAT errors or unrecoverable clusters. Check free space: the runtime expects ≥ 200 MB free for the diagnostic buffer queue.
9. Compare firmware against the Siemens bulletin database. Open Siemens Industry Online Support, navigate to Product Support → SIMOTION D445 → Support → Firmware downloads → Release notes. Search for "F360:BE02" or "BackgroundTask". Note that fixes for known F360:BE02 issues are bundled in HF releases (see §10).
10. Open a Siemens support request if no software or hardware root cause is identified. Attach the diagnostic buffer, the project archive, the DCC chart, the topology screenshot, and the firmware version.

7. Solutions by Root Cause

7.1 If the BackgroundTask has a runaway loop

Move the loop out of BackgroundTask. SIMOTION supports the IPO, Servo, ServoFast, and a free-running timer task. Long-running logic belongs in a Timer task scheduled at the desired cycle (e.g. 100 ms) with priority below Servo but with a longer maximum execution budget.

Refactor example, in Structured Text (ST) for SIMOTION V5.x:

// BEFORE — blocks BackgroundTask
WHILE bPumpRunning DO
    rPressure := _getAnalogInput(aiPressure);
    _setAnalogOutput(aqValve, rPressure * 0.5);
    _waitTime(t#200ms); // forbidden in BackgroundTask
END_WHILE;

// AFTER — moved to a 100 ms Timer task "LoggingTask"
IF bPumpRunning THEN
    rPressure := _getAnalogInput(aiPressure);
    _setAnalogOutput(aqValve, rPressure * 0.5);
END_IF;
// Done. _waitTime removed; the Timer task itself provides the cycle.

Pattern rules for BackgroundTask:

• No _waitTime of any value other than t#0s.
• No PRINT in online mode — route to a buffer and flush from a slow task.
• Wrap all _fileSystem calls in a watchdog of two task cycles; abort the call and log the error if not returned.
• Bound WHILE loops with a counter: FOR i := 1 TO 50 DO ... END_FOR;.

7.2 If DCC is saturating the slave

Open the DCC chart in offline mode and audit the block count. A SIMOTION D445 with firmware 5.4 supports up to 600 DCC blocks per slave; sustainable closed-loop performance is achieved at < 350 blocks. Strip diagnostic blocks that are only active during commissioning:

• Remove unused Trace blocks.
• Convert Scope blocks to manual start only.
• Replace fixed sample-time regulators with a sample-time selector that drops to a slower rate in steady state.
• Re-time the DCC: DCC → Compile → Statistics. Compile time > 1.5 ms is a warning; > 2.5 ms is a fault candidate.

7.3 If CU-Link is saturated

The SM150 control unit typically polls the D445 for setpoints at 4 ms. If the D445 misses the poll window, the SM150 flags a follow-on fault (e.g. F08501 in SINAMICS). Adjust the topology:

• Set the PROFINET send clock to 1 ms (D445 supports this from firmware 5.2 onward).
• Reduce the reduction ratio of the D445↔SM150 telegram to 2:1 (8 ms update) for non-critical data.
• Verify the fiber-optic link budget: < −3 dBm is the rule of thumb for hot strip mill cabinet environments.

7.4 If the CFast card is the cause

Replace the CFast card with a Siemens-approved part (Siemens 6AU1900-0AB10 or 6AU1900-0AB20 for current D445 generation). Re-image the runtime and re-load the project. Run dosfsck on the old card outside the cell to confirm the hardware failure.

7.5 If the firmware is the cause

Apply the latest hotfix for the installed firmware branch. For D445, the following firmware versions include documented fixes for F360:BE02 conditions:

Always verify with the SIMOTION SCOUT → Target system → Version view output and cross-reference against the SIMOTION D445 product support page release notes before upgrading.

8. Verification Procedure

1. Download the corrected project to the D445. Do a warm restart (RUN → STOP → RUN). Confirm the diagnostic buffer no longer raises F360:BE02 over a 30-minute observation window.
2. Open Task Trace and verify the maximum execution time of BackgroundTask stays < 50% of the cycle time across all operating points of the mill, including coiler acceleration and thread-out.
3. Run a controlled rolling at 50% speed and then at design speed. Watch the slave processor load in DCC → Runtime measurement. Confirm < 70% utilization under all conditions.
4. Force a test fault: temporarily inject a 5 s _waitTime in a non-critical BackgroundTask (in a test project, not on the production line). Confirm the fault is detected and the system recovers after the wait is removed.
5. Mark the diagnostic buffer and the task trace as the new baseline; archive with the project.
6. Re-enable any inhibited alarms in the HMI. The SINAMICS S120 alarm mask on the SM150 should match the post-repair state.

9. Related SIMOTION D4x5 Diagnostic Events

Operators frequently confuse F360:BE02 with related events. The matrix below is the quick reference for the control room.

10. Field-Proven Caveats

11. Quick Reference: BackgroundTask Settings on D445

12. Summary

The SIMOTION D445 F360:BE02 sign-of-life failure on a Sinamics SM150 hot strip mill is, in the majority of cases, a runaway BackgroundTask in the SIMOTION execution system, often triggered by a user MCC/ST loop, a blocking online write, or a saturated DCC chart. The diagnostic buffer entries 0xC4 50 in additional info 4/5 and the "Timeout BackgroundTask" text are the unambiguous marker.

Capture the diagnostic buffer, open the task trace, profile the BackgroundTask and DCC runtime, audit the CFast card, and compare the firmware against the Siemens bulletin database. Move long-running or blocking logic out of BackgroundTask; arm the watchdog; verify in a controlled rolling. If the cause remains elusive, open a Siemens support request with the diagnostic buffer, project archive, and firmware version.

Frequently Asked Questions