Comparing Alarm_8P vs Notify_8P in S7-400 Logic and Resolving Missing Alarms After WinCC Restarts

In SIMATIC PCS 7, the Alarm_8P (SFB 35) block is engineered for process alarms requiring acknowledgment and persistent state synchronization, whereas Notify_8P (SFB 36) is designed exclusively for unacknowledged, transient event notifications. When WinCC restarts without a controller reboot, active events generated by Notify_8P do not appear in the active alarm list (displaying EventRow = 65535 or missing entirely) because Notify_8P transmits data only on the rising/falling edge of an event and does not support WinCC startup state synchronization. For critical analog limits and sensor faults, engineers must replace Notify_8P with Alarm_8P to guarantee automatic alarm synchronization.

Architecture of S7-400 Message Blocks: Alarm_8P vs Notify_8P

In SIMATIC PCS 7 and STEP 7 S7-400 automation controllers, generating chronological, time-stamped alarms at the controller level relies on integrated System Function Blocks (SFBs) built into CPU firmware:
* Alarm_8P (SFB 35):
Processes up to eight discrete alarm signals (SIG_1 to SIG_8) along with associated process values (SD_1 to SD_10). Designed for process-critical alarms requiring operator acknowledgment, persistent active state tracking, and regulatory audit compliance.
* Notify_8P (SFB 36):
Processes up to eight discrete notification signals (SIG_1 to SIG_8) with associated process values. Designed for informational operational notifications (e.g., "Filter self-clean started", "Lubrication cycle completed") where operator acknowledgment is neither required nor permitted.
* The Common Misconception:
Engineers looking to save CPU work memory or message instances sometimes use Notify_8P to report process limits (e.g., analog LoLo, Lo, Hi, HiHi) or sensor masking flags, erroneously assuming Notify_8P behaves like an unacknowledged alarm. This introduces severe operational visibility failures.

Why Notify_8P Messages Vanish Following a WinCC OS Restart

When an analog transmitter breaches a threshold (e.g., HiHi pressure alarm), Notify_8P detects the edge transition (0 -> 1), captures a high-resolution CPU timestamp, and transmits an event telegram across the plant bus to WinCC Alarm Logging.

However, consider the following real-world operational scenario:
1. The HiHi condition remains active in the plant (the sensor remains above threshold).
2. The WinCC OS Server is restarted for scheduled maintenance, or an OS redundancy switchover occurs.
3. When WinCC re-launches and opens the WinCC Alarm Control (Active Alarms list), the HiHi alarm is completely missing!
4. The WinCC alarm buffer reports internal error status or shows EventRow = 65535 (unlinked event handle).
5. The alarm will never display on the operator screen until the field sensor physically clears (1 -> 0) and trips again (0 -> 1), leaving plant operators completely blind to an ongoing hazardous overpressure condition.

The WinCC Alarm State Synchronization Protocol (Startup Sync)

The fundamental technical difference between Alarm_8P and Notify_8P lies in Active State Synchronization:

How Alarm_8P Synchronizes:
The S7-400 CPU firmware maintains a dedicated Message State Buffer for all Alarm_8P instances. When WinCC boots up, its Alarm Logging channel initiates an alarm synchronization handshake with the CPU. The CPU systematically transmits the current binary state (Active / Cleared / Acknowledged) of every Alarm_8P instance. Consequently, all ongoing active alarms instantly populate the operator's alarm screen.
How Notify_8P Operates:
Notify_8P is an edge-triggered, fire-and-forget block. It does not maintain an active state table in CPU firmware and does not respond to WinCC startup synchronization queries. It only transmits a telegram at the exact moment a signal toggles. If WinCC was offline when the edge occurred, or if WinCC restarts while the condition persists, no telegram is ever sent.

Comparing Alarm_8P (SFB 35) vs Notify_8P (SFB 36)

The following table details the architectural and functional distinctions between S7-400 message blocks:

Functional FeatureAlarm_8P (SFB 35)Notify_8P (SFB 36)Primary IntentProcess alarms & safety tripsInformational notificationsOperator AcknowledgmentSupported (Mandatory or Optional)Strictly not supportedActive State TrackingMaintained in CPU firmware memoryNot maintained (edge event only)WinCC Startup SynchronizationFully supported (re-populates active list)Not supported (messages lost upon restart)Message Classes in WinCCAlarm, Warning, ToleranceNotification, InformationCPU Resource ConsumptionModerate (manages state & ack queues)Low (transient telegram generation)Associated Values (SD)Up to 10 process valuesUp to 10 process valuesRecommended UsageSensor faults, trips, process limitsMode changes, status notifications

Diagnostic Matrix: Selecting Between Alarm_8P and Notify_8P

The following matrix guides correct block selection based on operational requirements:

Operational RequirementCorrect BlockJustificationHigh/Low Process Thresholds (LoLo, HiHi)Alarm_8PMust remain visible in active alarm list until cleared; requires syncSensor Fault / Passivation / Wire BreakAlarm_8PCritical equipment fault; operators must see active status after OS rebootSensor Inhibit / Maintenance Bypass ActiveAlarm_8PMaintenance override must remain prominently visible to all shiftsMotor Started / Stopped State TransitionNotify_8PTransient event log; no need to remain in active alarm listRoutine Sequence Phase TransitionNotify_8PHistorical event record for batch logs; no acknowledgment requiredPeriodic Calibration CompletedNotify_8PInformational confirmation message; fire-and-forget

Step-by-Step Procedure to Replace Notify_8P with Alarm_8P

To eliminate message loss and ensure complete startup synchronization:

Modify SCL / CFC Source Blocks:
* Open the custom technological block source code in the S7 Program sources.
* Replace the call and declaration of SFB 36 (Notify_8P) with SFB 35 (Alarm_8P).
* Under VAR, update the multi-instance declaration:
scl // Replace: inst_Notify : Notify_8P; inst_Alarm : Alarm_8P;
Assign Message Attributes in SCL:
* Ensure the message ID attribute { S7_server := 'alarm_archiv'; S7_a_type := 'alarm_8p' } is declared on the instance.
Compile SCL and Update Block Types in CFC:
* Compile the SCL source file.
* In SIMATIC Manager, select Options > Charts > Update Block Types.
* Select the modified block and allow the wizard to update all CFC instances.
Configure Message Properties in CFC:
* Open the CFC chart containing the block.
* Right-click the block > Object Properties > Messages.
* Assign message classes (e.g., Alarm - High, Warning - Low).
* Configure acknowledgment options (set to With acknowledgment for trips, or Without acknowledgment if only auto-clearing is desired).
Compile AS and OS:
* Perform a CFC compilation (Scope: Changes only).
* Perform an OS compilation (Compile OS) to generate updated message definitions in WinCC Alarm Logging.

Verification

Verify that alarm state synchronization operates reliably:
1. In the Automation Station, force an analog limit condition (e.g., set HiHi = TRUE); confirm that the alarm appears instantly in the WinCC Alarm Control.
2. While the alarm remains active in the field, close WinCC Explorer on the OS server and re-open it (simulate an OS restart).
3. Activate WinCC Runtime; open the Alarm Control and verify that the active HiHi alarm immediately reappears with its original CPU timestamp.
4. Clear the field condition (HiHi = FALSE); verify that the alarm clears or transitions to the "Outgoing" state in the alarm journal.

Limitations and Operational Precautions

Communication Resource Limits: Alarm_8P blocks utilize active communication buffers in the S7-400 CPU. Placing hundreds of Alarm_8P instances in high-frequency cyclic OBs (e.g., OB35 at 50 ms) without throttling can exhaust CPU communication buffers and trigger EVENT_LOST errors.
Delta Download Caveats: Replacing Notify_8P with Alarm_8P inside an existing Function Block alters the block's internal instance data structure. In PCS 7, modifying structural declarations requires updating block types and downloading in CPU STOP mode if interface changes cannot be accommodated in RUN mode.
Alarm Flooding: Always implement deadbands and delay timers on analog limits before passing signals to Alarm_8P to prevent chattering alarms around trip thresholds.
Commercial Accuracy: Standard PCS 7 message processing is included with S7-400 CPU firmware and standard PCS 7 engineering packages (6ES7658-2CX58-0YB5). Validate license allocations with an authorized Siemens distributor quotation.

Engineer FAQ

Can Alarm_8P be configured so that operators do not need to acknowledge the alarm?

Yes. In the CFC Block Properties > Messages dialog, you can assign the message to a message class configured as 'Without acknowledgment' (e.g., Status Message or Operating Message). It will behave without requiring acknowledgment while retaining full startup synchronization.

What does the WinCC error 'EventRow = 65535' mean?

An EventRow value of 65535 indicates an invalid or unmapped row pointer in the WinCC Alarm Control grid, typically occurring when a message telegram is received for a tag handle that cannot be correlated to the active message database.

How many process values can be transmitted alongside an Alarm_8P telegram?

Alarm_8P supports up to 10 associated values (SD_1 to SD_10) of various data types (REAL, INT, DINT, STRING), which can be embedded directly into the WinCC alarm message text (e.g., 'Boiler pressure exceeded: @1%f@ bar').

Does Notify_8P consume fewer CPU resources than Alarm_8P?

Yes, marginally, because Notify_8P does not maintain active state tables or acknowledgment monitoring queues in CPU firmware. However, this marginal saving does not justify its use for safety-relevant or operational process limits.