Customizing OS Area Identifiers and Unlocking $$AREA$$ Properties in PCS 7 Alarm Logging

In SIMATIC PCS 7, alarm messages automatically derive their OS Area identifier from Level 1 of the Plant Hierarchy via the macro keyword $$AREA$$. For blocks placed in sub-hierarchy folders (Level 2 or deeper), the area ID continues to report the Level 1 parent folder. To assign custom or sub-folder area names to alarms without modifying code, unlock the padlock icon on the OS area attribute in the block's Special Object Properties > Messages dialog, and bulk-assign the desired sub-area names using the Process Object View.

Architecture of Plant Hierarchy Area Mapping in Alarm Logging

In SIMATIC PCS 7, alarms displayed in the WinCC Alarm Logging list (WinCC AlarmControl) are categorized by their technological OS Area (e.g., Boiler_Area, Distillation_Area, Water_Treatment). This classification is critical because:
* It drives the top-level Group Display (Sammelanzeige) in @Overview1.pdl.
* It enforces User Administrator Area Authorization: an operator assigned only to Area 1 cannot acknowledge alarms belonging to Area 2.
* It enables operators to filter the alarm list by technological sections.

By default, the PCS 7 OS Compiler generates the OS Area attribute using the macro keyword $$AREA$$.

In the Plant Hierarchy (PH), Siemens defines the top-most hierarchy level (Level 1) as the OS Area. When an engineer organizes a project with deeper hierarchy levels (e.g., Plant / Area_01 / Unit_Reactor / Sub_Feed_Pumps), all alarms generated by blocks within Sub_Feed_Pumps still report their area as Area_01.

When engineers attempt to edit the area string in CFC or the Process Object View, they find the field disabled and locked with a small padlock icon.

OS Area Assignment and $$AREA$$ Keyword Behavior Matrix

Understand how the OS Area attribute is derived and unlocked across the engineering system:

Configuration MethodOS Area String in Message ConfigDefault Padlock StateRuntime Area Behavior in WinCCFlexibilityStandard Plant Hierarchy$$AREA$$Locked (Checked)Strictly derived from Level 1 Plant Hierarchy folderAutomatic; locked to parent areaUnlocked Custom AreaExplicit String (e.g., Reactor_Unit)Unlocked (Unchecked)Reports explicit technological unit in Alarm LoggingHigh; permits granular area segregationProcess Object View Bulk EditCustom Area per SubfolderUnlocked via master blockGranular area assignment across hundreds of blocksFast; project-wide consistencyManual WinCC Alarm Logging EditOverwritten in CS DBN/AOverwritten during next OS CompilationProhibited; changes do not persist

System standard: Never modify alarm area strings directly inside WinCC; always configure in STEP 7.

Unlocking the OS Area Padlock in STEP 7 Block Properties

To permit custom area naming on standardized blocks (such as VlvS, MotL, MonAnL):

Locate the Master Block in SIMATIC Manager:
* Open the project in the Component View.
* Navigate to the S7 Program's Blocks folder (or master data library).
* Locate the target block (e.g., FB1858 for VlvS or FB1850 for MotL).
Open Message Properties:
* Right-click the block, select Special Object Properties > Messages.
* In the Message Configuration dialog, click the More button.
Unlock the OS Area Padlock:
* Locate the section labeled OS Area.
* Notice the small padlock checkbox next to $$AREA$$. By default, this box is checked (locked).
* Uncheck the padlock checkbox.
* Click OK to save the modified block template.
Propagate Block Type Update:
* Open any CFC chart.
* Select Options > Block Types.
* Highlight the modified block and click New Version / Update.
* The compiler updates all instances in the project, unlocking the OS Area field across all charts.

Bulk-Editing Sub-Area Identifiers in Process Object View

Once unlocked, assign specific sub-areas in bulk without opening individual charts:

Open Process Object View:
* In SIMATIC Manager, select View > Process Object View (or press the PO View toolbar icon).
Filter by Hierarchy Subfolder:
* In the left tree, select the target sub-hierarchy folder (e.g., Unit_Reactor).
* Switch to the Messages tab in the main grid.
Replace Area Identifiers:
* Locate the column OS area.
* The column will now be editable (no longer grayed out).
* Replace $$AREA$$ with the specific technological sub-area name (e.g., Reactor_01).
* Use standard copy/paste or fill-down to update all blocks in that subfolder instantly.
Compile OS:
* Execute Compile OS (Scope: Changes only).
* The OS Compiler writes the explicit area strings into the WinCC Alarm Logging database.

Verification

Verify custom area classification in WinCC Runtime:
1. Trigger an alarm on an equipment block residing in the sub-folder.
2. Open the WinCC Alarm List in Runtime.
3. Inspect the Area column in the alarm grid:
* Confirm that the alarm displays the customized sub-area string (e.g., Reactor_01) rather than the top-level parent folder name.
4. Filter alarms by Area: Confirm that filtering by Reactor_01 isolates only alarms belonging to that specific technological unit.

Limitations and Operational Precautions

Unlocking the OS area decouples the block from automatic Plant Hierarchy folder tracking. If you physically move an unlocked block to a different plant folder, its assigned OS area text will not update automatically; you must update it in PO View.
Ensure customized area names match valid technological areas defined in the WinCC User Administrator; assigning an unconfigured area name can prevent operators from acknowledging alarms.
Area names must not contain spaces, commas, or special characters (/, \, ', ").

Engineer FAQ

Can I use a macro keyword like $$SUBAREA$$?

No. STEP 7 only provides $$AREA$$ (resolves to OS Area) and $$BLOCK$$ (resolves to block instance name). Sub-areas must be entered as explicit text.

Why was the padlock locked by default by Siemens?

Siemens locks OS Area by default to enforce rigid Plant Hierarchy alignment, ensuring that group display hierarchies and operator authorization zones are maintained automatically.

Does updating block types require stopping the controller?

Unlocking message padlocks modifies block interface metadata in the offline database. It does not alter the compiled executable machine code; changes can be downloaded in RUN.