C_-_EA25WBM048_SPEC_PLC_Style_Guide_0.1.0_DRAFT.pdf

West Basin Municipal Water District 17140 Avalon Blvd Carson, CA 90746 Phone: (310) 217-2411 www.WestBasinCA.gov

PCS Standards

PLC Style Guide v.0.1.0

West Basin Municipal Water District

Document PLC Style Guide

Revision Number 0.1.0

Effective Date 8/11/2026

Author Adrian Leon

Reviewed by Kaylee Halliday, Alex Coker

Prepared By:

9050 Irvine Center Drive Irvine, CA 92618

(949) 769-6000 www.eaintegrator.com

PLC Style Guide v0.1.0 EA Project Number: EA25WBM048

17140 Avalon Blvd, Carson, CA 90746 Revision: 0.1.0 Tel 310-217-2411 Effective Date: 8/11/2026 www.WestBasinCA.Gov Page Number: 2 of 22

History Revision Date Description of Change Author Reviewed

0.1.0 8/11/2026 Draft release for client review AL KH, AC

Table of Contents 1 Overview

1.1 Purpose

1.2 Acronyms and Terms

1.3 Supplemental Documents

1.3.1 HMI Style Guide

1.3.2 Standards Implementation Guide

1.3.3 Standards Operating Guide

1.3.4 PCS Tag Standards

2 Program Organization

2.1 General Programming Notes

2.2 PLC Settings

2.2.1 M580 PLCs

2.2.2 Remote I/O Racks

2.2.3 Communication Modules

2.3 Internal PLC Setpoints

2.4 Tasks

2.5 Functional Modules

2.6 Sections

2.6.1 Looping Code

2.7 Derived Function Blocks (DFB)

3 I/O Configuration

3.1 DI Handling

3.2 AI Handling

3.3 DO Handling

3.4 AO Handling

3.5 Communication Handling

4 Language Standards

4.1 Function Block Diagram

4.2 Structured Text

4.3 Ladder Diagram

5 Commenting

5.1 Function Block Diagram

5.2 Structured Text

5.3 Ladder Diagram

6 Tag Configuration

6.1 Descriptions

www.WestBasinCA.Gov Page Number: 3 of 22

6.2 Data Types

6.3 Derived Data Types (DDT)

www.WestBasinCA.Gov Page Number: 4 of 22

1 Overview

1.1 Purpose

This specification defines the configuration and programming standards for the PLC programs at West Basin Municipal Water District (the District). These standards have been developed by Enterprise Automation and are intended for use with Schneider’s EcoStruxure Control Expert development environment. These standards are intended for use with a suite of standards documentation that defines PLC and HMI practices (see Supplemental Documents).

1.2 Acronyms and Terms

For the remainder of the document the following acronyms will be used.

Term Description

WBMWD, the District “West Basin Municipal Water District”

EA “Enterprise Automation” (Integrator)

PLC

“Programmable Logic Controller”: The industrially hardened controllers that interface with the instrumentation, valves, pumps, etc., and control the automated processes (or simply collect information from any non-automated systems).

Device A term encompassing both the repeatable PLC code and the PCS integration (graphics, tags, historization, etc.) that represent a standardized unit of the system, i.e., “the Analog Valve device”

PCS Process Control System

DFB “Derived Function Block”

DDT “Derived Data Type” www.WestBasinCA.Gov Page Number: 5 of 22

1.3 Supplemental Documents

1.3.1 HMI Style Guide

SPEC HMI Style Guide 1.0.0

1.3.2 Standards Implementation Guide

SPEC Standards Implementation Guide 1.0.0

1.3.3 Standards Operating Guide

SPEC Standards Operating Guide 1.0.0

1.3.4 PCS Tag Standards

SPEC PCS Tag Standards 1.0.0 www.WestBasinCA.Gov Page Number: 6 of 22

2 Program Organization

2.1 General Programming Notes

The project settings should be modified to allow tags to begin with numbers so the PLC tag naming standards can be followed (Project Settings -> Variables -> Allow Leading Digits) as shown in the screenshot below.

www.WestBasinCA.Gov Page Number: 7 of 22

2.2 PLC Settings

2.2.1 M580 PLCs

2.2.1.1 CPU Settings

All M580 processors shall be configured with the following settings:

Parameter Value Configuration > Run/Stop input Disabled Configuration > Memory protect Disabled Configuration > Automatic start in Run Disabled Configuration > Initialize %MWi on cold start Enabled Configuration > Cold Start Only Disabled Configuration > Support Quantum Remote Drops Disabled Configuration > 0x / %M 1504 Configuration > 4x / %MW 2048 Configuration > 1x / %I 1504 Configuration > 3x / %IW 2048 Configuration > %KW 256 Configuration > Online modification in RUN or STOP Enabled Hot Standby > Allow Logic Mismatch Disabled Hot Standby > CPU executes First section

2.2.1.2 CPU EIO Settings

Parameter Value Security > FTP Disabled Security > TFTP Enabled Security > HTTPS Disabled Security > DHCP / BOOTP Enabled Security > SNMP Disabled Security > EIP Enabled Security > Engineering Link Mode Full Access Security > Access Control Disabled IP Configuration > Main IP address [See network drawings] IP Configuration > IP address A [See network drawings] IP Configuration > Subnet mask [See network drawings] IP Configuration > Gateway address [See network drawings] RSTP > Bridge Priority Root(0) SNMP Blank NTP > NTP Disabled Service Port > Service Port Enabled Service Port > Service Port Mode Access

Halliday, Kaylee These will all be confirmed and updated in the construction phase www.WestBasinCA.Gov Page Number: 8 of 22

2.2.2 Remote I/O Racks

2.2.2.1 CRA Module Settings

All remote I/O CRA modules shall be configured with the following settings:

Parameter Value Device DDT > Name [See network drawings] RSTP > Bridge Priority Participant(32768) SNMP Blank Service Port > Service Port Enabled Service Port > Service Port Mode Access Parameters > Hold up time 1000 Parameters > Custom RPI Periodic Time Stamping > On buffer full Stop the recording Time Stamping > On power on Nothing Time Stamping > On STOP to RUN Nothing

2.2.3 Communication Modules

2.2.3.1 NOC Module Settings

All NOC module networks shall be configured with the following settings:

Parameter Value Configuration > Configuration Type Static Configuration > Main IP address [See network drawings] Configuration > Subnet mask [See network drawings] Configuration > Gateway [See network drawings] Configuration > Automatic Device(s) subnet update Disabled www.WestBasinCA.Gov Page Number: 9 of 22

2.2.3.2 NUA Module Settings

All NUA module networks shall be configured with the following settings:

Parameter Value IPConfig > NUA (A) Control Port Enabled IPConfig > NUA (A) IPv6 Disabled IPConfig > NUA (A) IPv4 Mode Static IPConfig > NUA (A) IPv4 IPv4@ [See network drawings] IPConfig > NUA (A) IPv4 Subnet mask [See network drawings] IPConfig > NUA (A) IPv4 Default gateway [See network drawings] IPConfig > NUA (A) IPv4 Backplane port IPv4@ [See network drawings] IPConfig > NUA (A) OPCUA TCP Listening Port By default NTP > Primary NTP Server IP address [See network drawings] NTP > Secondary NTP Server IP address [See network drawings] SNMP Blank

2.2.3.3 NOE Module Network Settings

All NOE module networks shall be configured with the following settings:

Parameter Value Module Utilities > SMTP NO Module Utilities > Global Data NO Module Utilities > Address Server NO Module Utilities > NTP NO Security > Firmware Upgrade & FDR Disabled Security > Web Access Disabled IP Configuration Configured IP Configuration > IP address [See network drawings] IP Configuration > Subnet mask [See network drawings] IP Configuration > Gateway address [See network drawings] IP Configuration > Ethernet Configuration Ethernet II Messaging > Access Control Disabled SNMP Default/Disabled www.WestBasinCA.Gov Page Number: 10 of 22

2.3 Internal PLC Setpoints

Most PLC programs will require setpoints that must be set by the programmer during the commissioning of the project. These setpoints are only available in the PLC program and do not have an associated variable in the PCS. In order to preserve the value of these setpoints in the event of memory loss, these setpoints should have their values hardcoded by using a MOVE function block to write the desired value into the un-located (not addressed) setpoint tag. This will require the programmer to make an online modification to the program whenever an internal setpoint changes since the value cannot be written to using an animation table.

2.4 Tasks

These standards are written under the assumption that all programming is being done within a single, continuous task. No additional periodic tasks, alarming, or fault handling are implemented. By configuring all logic within one “Main” task, the code is much easier to read sequentially and to troubleshoot.

There are many recognized performance benefits of using periodic tasks and other architectures of code execution. These benefits include improved scan time and improved timing accuracy. However, since programming at the District tends to support large physical processes (time scales of seconds to hours), it is assumed that the millisecond and microsecond improvements to performance are not necessary. For this reason, a singular continuous task is recommended for its improved readability over all other architectures.

The only task within the PLC should be “MAST”, executed continuously. Before a full deploy, the program should be tested to ensure that the scan time is significantly shorter than 500ms (target range <20 ms). Configure a watchdog on the MAST for 500ms.

2.5 Functional Modules

Control Expert gives the user the ability to assign functional modules to each code section. Functional modules should be used to divide the process sections into high-level groups. The following functional modules will exist for all programs: SYSTEM and IO. These functional groups contain critical code sections that are defined for all PLC programs.

Additional functional modules should be created when there is a clear division between physical systems, e.g. chemical dosing versus a filtering process. Functional module names use up to six characters in all caps.

Coker, Alex Evaluate after implementation, hot standby implementations can easily reach 50ms due to overheads www.WestBasinCA.Gov Page Number: 11 of 22

2.6 Sections

Section names should be assigned to a functional module, with a short description of the code section with no spaces as its name. The following SYSTEM sections will exist for all programs and should be executed first: PLCStatus, ClockSync, and HotStandbyMgmt. All IO input code sections must be executed next, before any process code sections (e.g., DIMapping, AIMapping). The last code sections in the program must be all IO output code (e.g., DOMapping, AOMapping).

It is recommended that function block code does not exceed 150 columns in width so that the logic is easily readable when connected to the PLC or when printing landscape on 11x17 paper. Tag names on function blocks should not overlap each other and function block links should not cross.

Sections should be designed with the following maximum limits:

Language Size Limit Ladder 100 lines Structured Text 1000 lines Instruction List 1000 lines Function Block Diagram 300 blocks

2.6.1 Looping Code

Structured text allows the configuration of loops (e.g., FOR-loops) in which certain sections of code are executed multiple times within a single scan of the task. Using loops in structured text is acceptable as long as the loop is clearly commented and contains an exit condition that will guarantee that the loop does not stall and prevent progress of the scan.

2.7 Derived Function Blocks (DFB)

DFBs are recommended as the primary method for employing repeatable code. DFBs allow the definition of a common “function” that can then be called multiple places within the programming.

Live values from each instance of a DFB can be individually displayed at runtime. This means that the code remains fully readable at runtime.

www.WestBasinCA.Gov Page Number: 12 of 22

3 I/O Configuration The standards below are intended to ensure consistent handling of I/O within the programming regardless of the physical configuration used.

Input and output channels are referenced using the built-in Device DDTs. These Device DDTs are available with all newer Schneider Electric PLC models.

3.1 DI Handling

Elements of the I/O card data type (e.g., PLC0_D0_R0_S02.DIS_CH_IN[0].VALUE) should not be used directly within the program. Instead, these elements should be written into DDT_DiscreteInput within a discrete input handling section to ensure values do not change unexpectedly throughout the scan.

Digital input mapping shall occur in a function block section called “DIMapping”. This section also handles debouncing of discrete alarms using the discrete alarm function blocks. If a DI channel is spare, the line should be commented with “SPARE”. This section should be organized with clear distinctions between each rack and between each DI card within that rack.

For each DI point, move the value of the point from the I/O card (“.VALUE” extension) into the “.Input” element of DDT_DiscreteInput.

For each DI point, move the inverse health status of the point from the I/O card (“.CH_HEALTH” extension) into the “.ChannelFault” element of DDT_DiscreteInput.

www.WestBasinCA.Gov Page Number: 13 of 22

3.2 AI Handling

Spare channels should be disabled (Used checkbox unchecked). The range should be configured as “1..5 V / 4..20 mA” with a scaling of 0-11,429 and overflow checks enabled.

Scaling from the raw channel value to the engineering value is handled by the DFB_AnalogInput.

For an example configuration, see screenshots below.

Elements of the I/O card data type (e.g., PLC0_D0_R0_S05.ANA_CH_IN[0].ANA.VALUE) should not be used directly within the program. Instead, these elements should be written into DDT_AnalogInput within an analog input handling section to ensure values do not change unexpectedly throughout the scan.

Analog input mapping shall occur in a function block section called “AIMapping”. The function blocks within this section should be formatted so that each analog point is programmed in the order they are wired to the analog channels. If an AI channel is spare, the line should be commented with “(*SPARE*)”. This section should be organized with clear distinctions between each rack and between each AI card within that rack.

For each AI channel, read the value of the channel from the I/O card (“.VALUE” extension) into the “.Input” element of DDT_AnalogInput.

For each AI channel, read the inverse health status of the channel from the I/O card (“.CH_HEALTH” extension) into the “.ChannelFault” element of DDT_AnalogInput.

www.WestBasinCA.Gov Page Number: 14 of 22

For each AI channel, use the DDT_AnalogInput to configure scaling, deadband, and all other features available in the standard (see Standards Implementation Guide for details).

Insert screenshot once standards are implemented www.WestBasinCA.Gov Page Number: 15 of 22

3.3 DO Handling

Unless otherwise required for process or safety reasons, output state should be configured with the following settings for all points:

Reactive: Automatic

Fallback mode: Maintain

Elements of the I/O card data type (e.g., PLC0_D0_R0_S04.DIS_CH_OUT[0].VALUE) should not be used directly within the program. Instead, these elements should be written into DDT_DiscreteOutput within a discrete output handling section.

Digital output mapping shall occur in a function block section called “DOMapping”. If a DO channel is spare, the line should be commented with “SPARE”. This section should be organized with clear distinctions between each rack and between each DO card within that rack.

For each DO point, move the “.Output” element of DDT_DiscreteOutput into value of the I/O card (“.VALUE” extension).

For each DO point, move the inverse health status of the point from the I/O card (“.CH_HEALTH” extension) into the “.ChannelFault” element of DDT_DiscreteOutput.

www.WestBasinCA.Gov Page Number: 16 of 22

3.4 AO Handling

The Range should be configured as “4..20 mA” with a scaling of 0-21,622 and overflow checks enabled. Unless otherwise required for process or safety reasons, output state should be configured with the following settings for all points:

Fallback: Enabled

Fallback value: 0

Wiring CTRL: Enabled

Scaling from the engineering value to the raw channel value is handled by the DFB_AnalogOutput.

For an example configuration of a 4-20mA transmitter, see below.

Elements of the I/O card data type (e.g., PLC0_D0_R0_S06.ANA_CH_OUT [0].ANA.VALUE) should not be used directly within the program. Instead, these elements should be written into DDT_AnalogOutput within an analog output handling section.

Analog output mapping shall occur in a function block section called “AOMapping”. The function blocks within this section should be formatted so that each analog point is programmed in the order they are wired to the analog channels. If an AO channel is spare, the line should be commented with “(*SPARE*)”. This section should be organized with clear distinctions between each rack and between each AO card within that rack.

For each AO channel, write the “.Output” element of DDT_AnalogOutput into value of the I/O card (“.VALUE” extension).

For each AO channel, read the inverse health status of the channel from the I/O card (“.CH_HEALTH” extension) into the “. ChannelFault” element of DDT_AnalogOutput.

For each AO channel, use the DFB_AnalogOutput to configure scaling and all other features available in the standard (see Standards Implementation Guide for details).

Insert screenshot once standards are implemented www.WestBasinCA.Gov Page Number: 17 of 22

3.5 Communication Handling

Communication between PLCs should be achieved by Modbus reads only, using DFB_CommRead.

These blocks use a token system to ensure only one message is active at a time. See the Standards Implementation Guide for details on communication handling devices and sections.

www.WestBasinCA.Gov Page Number: 18 of 22

4 Language Standards Control Expert software supports the five IEC PLC programming languages as well as ladder logic

984. However, new projects should only be programmed using function block diagram (FBD) or structured text. The sections below describe when each language should be used.

Legacy (or existing) code may have been written in one of the other IEC PLC programming languages.

Updates or modifications to the existing code are executed in the standing language for continuity.

Legacy code may be replaced with function block or structured text during a future project at the direction of the District.

4.1 Function Block Diagram

Function block diagram is desirable for handling functions that can run continuously and that do not depend on execution order to calculate correctly. Compared to other languages, it excels in its legibility for functions with multiple inputs and outputs, such as most DFBs.

Function block is the preferred language for all code within the PLC.

4.2 Structured Text

Structured text is desirable for handling functions that require complex or non-linear execution order.

Compared to other languages, it excels in its ability to handle loops and arrays. Structured text allows the most flexible options for commenting and code structure, but it is typically less legible for reading runtime values.

Structured text is recommended for code that requires complex calculations (e.g., polynomial equations) or loops. Described more broadly, structured text is recommended for code that is too complicated to legibly express within function block. However, function block is still the preferred language for the majority of programming.

Since structured text can be generated and manipulated by any text editor (with functions such as search-and-replace), functions that are repeated many times may be best implemented within structured text (e.g., handling 20+ I/O points).

4.3 Ladder Diagram

Ladder diagram should be avoided wherever possible with a strong preference for Function Block Diagram or Structured Text.

www.WestBasinCA.Gov Page Number: 19 of 22

5 Commenting Comments are crucial to the legibility and maintenance of a PLC. Comments should be human-readable and should aid interpretation of the associated code. Direct translation of the code into text (e.g., “If State = 1, write 100 into valve’s command) is not sufficient for clarity. Instead, written descriptions should help guide the reader through the associated code (e.g., “When the system is online, fully open the valve”).

Comments should be written at multiple levels of specificity, so that general intent and specific execution are both clearly explained. Use the following hierarchy to guide all commenting:

Section Description- At the top of each program section, describe the intent of this section of code as well as any interactions between the section and other sections.

Completion On Production Transition:

Section is called when On Production is initiated

Permissives and initiation are handled in other sections

Code Group Description- Within each section, highly related code is grouped together. Above each group, assign a name that clearly indicates this intent.

(* SECTION 2: Sequence Steps *)

Specific Code Description- Within each code group, explain the intent of each specific function.

This may require a comment on each line or function. Sometimes one comment may apply to multiple lines or functions if multiple functions contribute to one behavior.

(* Advance condition- On Production initiated (On Production transition called) *) www.WestBasinCA.Gov Page Number: 20 of 22

5.1 Function Block Diagram

Section Descriptions should appear at the top left of each page. Code group descriptions and specific code should be indented from the left of the page. In the case that the specific code description is relevant to a single function block, the description may be placed adjacent to that block on the page.

See below for example:

www.WestBasinCA.Gov Page Number: 21 of 22

5.2 Structured Text

Section Descriptions should appear at the top left of the program section. Code group descriptions should appear on their own line. Specific code descriptions should be placed to the far right on the same line as the code. Specific code descriptions should be indented out far enough that they are clearly distinct from the code. See below for example:

5.3 Ladder Diagram

Section Descriptions should appear at the top of the page. Specific code descriptions should be commented on the first rung of the relevant code. See below for example:

www.WestBasinCA.Gov Page Number: 22 of 22

6 Tag Configuration This section contains a brief summary of the tag configuration and usage within a program. See the PCS Tag Standards for more information.

6.1 Descriptions

All user-created tags should have an informative description that follow these rules:

A. Does not contain abbreviations (e.g., “Manual initiation request” instead of “Man init. req.”)

B. Uses mixed caps (not ALL CAPS)

C. Uses simple, human-readable language

D. Describes how to interpret the value of the tag when appropriate (e.g., “0 = disabled, 1 = enabled”)

6.2 Data Types

There are no restrictions on data types that may be used within a program. Data types that are composites of multiple primitive data types are also acceptable (e.g., DDTs, IODDTs, Device DDTs).

Aliases shall not be used within a program.

6.3 Derived Data Types (DDT)

DDTs can provide a standard structure for storing related data. Some pre-defined DDTs are available to interface with some of the District’s most common devices (see the Standards Implementation Guide). However, new DDTs can be defined if the programming warrants it.

Any time that values in the PLC must be linked to a template in the PCS, a DDT should be created to store the relevant tags for communication. This guarantees consistent communication between the attributes of the HMI template (which are the same for each instance) and the elements of the DDT (which are also the same for each instance). For individual tags that are not templated within the PCS, one-off controller tags are acceptable.

2.7 Derived Function Blocks (DFB)