C135 PCS 7 (PCS7)
6C
6 Cielo Ciencia y Tecnología
·Publicada en C135 PCS 7 (PCS7)

Message Generation in SIMATIC PCS 7 APL: Selecting Event Blocks vs Legacy ALARM_8P

Message Generation in SIMATIC PCS 7 APL: Selecting Event Blocks vs Legacy ALARM_8P

When engineering message generation within SIMATIC PCS 7 V8.1 and the Advanced Process Library (APL), engineers should always implement standard APL Event blocks (Event, EventNck, EventTs, Event16Ts) rather than calling legacy system function blocks (ALARM_8P / SFB 35) directly. While ALARM_8P is the underlying firmware communication mechanism that transmits messages to WinCC, the APL Event block (FB 1811) wraps ALARM_8P within a full technological interface—providing signal inversion, alarm incoming/outgoing delay timers, batch integration, maintenance bypass ('Out of Service' / 'Release for Maintenance'), native APL faceplates, and standardized alarm shelving. Direct usage of ALARM_8P is obsolete in modern PCS 7 architectures.

Table of Contents

The Evolution of Alarm Generation in SIMATIC PCS 7

In process automation, annunciating alarms to operators requires high-speed coordination between controller state changes and the operator station alarm logging database:

  • Legacy PCS 7 (Classic Library): In PCS 7 V4 through V7.0, engineers manually placed system function blocks:
  • ALARM_8P (SFB 35): Generates up to 8 acknowledgeable messages with 10 associated analog/string values.
  • NOTIFY (SFB 36): Generates unacknowledged operational messages.
  • Modern PCS 7 (Advanced Process Library): Introduced with PCS 7 V7.1 and standardized through V8.x and V9.x, the Advanced Process Library encapsulates ALARM_8P inside standardized technological blocks called Event blocks. These blocks eliminate manual message scripting while delivering comprehensive lifecycle alarm management conforming to ISA-18.2 / EEMUA 191.

Why Calling ALARM_8P Directly is Obsolete in APL Projects

While ALARM_8P remains functional in firmware, calling it directly introduces severe engineering disadvantages:

  1. No Alarm Time Delay: ALARM_8P triggers immediately upon a digital edge. Filtering contact chatter or mechanical switch bounce requires programming separate external timer blocks (TON / TimerP).
  2. Missing Maintenance Features: ALARM_8P lacks native support for 'Out of Service' (OosOp), 'Release for Maintenance', or interlocking bypass states, leading to nuisance alarms during maintenance.
  3. No Standard APL Faceplate: WinCC cannot generate a standardized APL operator faceplate for raw ALARM_8P blocks, preventing operators from inspecting alarm timestamps, signal statuses, or shelving alarms directly from graphics.
  4. No APL Quality Code Integration: Raw ALARM_8P cannot process the APL signal status byte (ST), ignoring sensor quality degradation.

Overview of the APL Event Block Family: Event, EventNck, EventTs

The PCS 7 Advanced Process Library provides four specialized Event blocks tailored to distinct operational requirements:

1. Event (FB 1811) - Acknowledgeable Process Messages

The primary message block for plant operations. Monitors up to 8 boolean inputs (In1 to In8), generates acknowledgeable alarm classes (e.g., Alarm High, Warning, Tolerance), and supports individual on/off delay timers.

2. EventNck (FB 1813) - Unacknowledged Operational Messages

Configured for operational status notifications (e.g., 'Pump auto-start initiated', 'Filter backwash completed') that do not require operator acknowledgement.

3. EventTs (FB 1815) - High-Precision Time-Stamped Messages

Integrates with hardware sequence of events (SOE) digital input modules (e.g., ET 200M with 1 ms time stamping). Captures the exact hardware edge timestamp and transmits it into WinCC Alarm Logging.

4. Event16Ts (FB 1817) - 16 Time-Stamped Messages

Expanded variant of EventTs supporting up to 16 time-stamped digital inputs in a single block.

Configuring the APL Event Block (FB 1811) in CFC

To deploy and configure the Event block:

  1. In CFC, open the PCS 7 AP Library and place Event (FB 1811) into a cyclic interrupt OB (e.g., OB35).
  2. Input Interconnections: Connect field boolean signals or trip conditions to inputs In1 through In8.
  3. Configure Signal Conditioning:
    * Set InvIn1 = 1 if the input signal requires logical inversion (e.g., fail-safe normally closed dry contact).
    * Set In1Delay (e.g., T#2s) to filter out momentary mechanical chatter before asserting the alarm.
  4. Message Text Parameterization:
    * Right-click the Event block -> Object Properties -> Messages.
    * Define customized message texts, event strings, message classes (Alarm, Warning, Tolerance), and assign associated process values (ExtVa101 to ExtVa110).
  5. Execute an OS compile to generate WinCC alarm records automatically.

Message Block Capability and Feature Comparison Matrix

The following table compares legacy ALARM_8P with the modern APL Event block family:

Feature / CapabilityLegacy ALARM_8P (SFB 35)APL Event (FB 1811)APL EventTs (FB 1815)Underlying MechanismDirect S7 Firmware CallWraps ALARM_8PWraps ALARM_8P + SOEIntegrated Time DelaysNone (Requires extra timer)Yes (InXDelay built-in)Handled by hardware SOESignal InversionNone (Requires inverter)Yes (InvInX built-in)Built-inAPL Faceplate SupportNoneNative APL FaceplateNative APL FaceplateAlarm Shelving (ISA-18.2)Not SupportedFully SupportedFully Supported1 ms Hardware SOE TimestampNot SupportedNot SupportedSupported (1 ms resolution)

Deploying APL Event blocks ensures full compliance with modern alarm management standards.

Verification

To verify that the APL Event block generates alarms correctly:
1. In CFC test mode, assert a fault condition on input In1 of the Event block.
2. Verify that after the configured In1Delay expires, the output Out1 transitions to TRUE.
3. In WinCC Runtime, observe the Alarm Logging window; confirm that the alarm appears with the configured message text, correct timestamp, and designated priority.
4. Click the message line to open the associated APL faceplate; verify that operator acknowledgement clears the unacknowledged alarm flashing state.
5. De-assert the fault; confirm that the outgoing message logs cleanly.

Limitations and Operational Precautions

  • Avoid creating hundreds of individual Event blocks for simple motor/valve trips; standard APL control blocks (MotL, VlvL) already include integrated ALARM_8P message engines.
  • Each instantiated Event block consumes communication resources and one AS RT Process Object (PO) license upon OS compilation if OCM is enabled.
  • Do not call ALARM_8P or Event blocks inside fast cyclic OBs (e.g., OB30 at 10 ms) without throttling, as rapid burst messages can overflow the CPU communication buffer.
  • Always validate final license quantities, module availability, and MLFBs against the applicable Siemens catalog and authorized distributor quotation.

Engineer FAQ

Does the APL Event block consume more CPU memory than ALARM_8P?

The Event block requires slightly more instance DB memory (approx. 200 bytes) due to its delay timers, inversion logic, and APL faceplate parameters, but the immense engineering and diagnostic benefits far outweigh the minor memory footprint.

Can I attach dynamic process values (like temperature or pressure) to the alarm text?

Yes. Connect the analog signal to associated value inputs ExtVa101 through ExtVa110. In the message configuration dialog, insert standard formatting tokens (e.g., @1%f@) to embed the value dynamically into the alarm message.

What is the difference between Event and EventNck?

Event requires operator acknowledgement (Ack), appearing in the unacknowledged alarm list until acknowledged. EventNck is an informational event that clears automatically when the condition normalizes without requiring manual operator acknowledgement.

Technical References

Related Articles

Related Tags

  • Alarm_8P
  • APL Event Block
  • EventTs
  • ISA-18.2 Alarming
  • Message Generation
6 respuestas