Necessity and Architectural Role of Channel Drivers in SIMATIC PCS 7 - Hardware Diagnostics and Signal Quality

Necessity and Architectural Role of Channel Drivers in SIMATIC PCS 7 - Hardware Diagnostics and Signal Quality

While it is technically possible to wire physical I/O addresses directly to technological blocks in SIMATIC PCS 7 Continuous Function Charts (CFC), utilizing standard channel drivers (such as Pcs7DiIn, Pcs7DoOu, Pcs7AnIn, and Pcs7AnOu from the Advanced Process Library) is an absolute engineering requirement for robust plant operation. Channel drivers decouple physical hardware addresses from technological logic, interface with module diagnostic drivers (MOD_D1, MOD_HA) generated by the PCS 7 Driver Generator, and automatically evaluate hardware faults (wire breaks, short circuits, power loss). When a fault occurs, the channel driver asserts output Bad = 1 and assigns quality code 16#00 (Bad), routing the error to the technological block's Control System Fault (CSF) input for operator alarm annunciation.

Table of Contents

The PCS 7 Driver Architecture: Decoupling Physical I/O from Technological Control

In traditional PLC programming (such as basic Step 7 LAD or third-party controllers), engineers frequently wire physical peripheral I/O addresses (e.g., IW 256 or Q 4.0) directly into application logic. In SIMATIC PCS 7, direct peripheral wiring is considered an anti-pattern that violates the core architecture of the system.

PCS 7 enforces a modular three-tier signal processing model:

  1. Physical Peripheral Tier: The hardware module in the ET 200 distributed I/O station.

  2. Channel Driver Tier: Signal-specific driver blocks (Pcs7DiIn, Pcs7DiOu, Pcs7AnIn, Pcs7AnOu, FbAnIn, FbDiIn) that read the peripheral address, evaluate signal validity, apply process scaling, and generate standardized structured signals.

  3. Technological Control Tier: Equipment control blocks (MotL, VlvL, PIDConL, MonAnL) that execute automation algorithms based purely on processed signals.

Hardware Diagnostics Integration and the Role of the Driver Generator

The most critical reason to deploy channel drivers is hardware diagnostic integration:

  • When you compile CFC charts with the option 'Generate Module Drivers' enabled, the PCS 7 Driver Generator automatically scans the Hardware Configuration (HW Config) and instantiates diagnostic blocks (MOD_D1, MOD_HA, RACK, SUBNET) in dedicated @-prefixed runtime groups.

  • These module drivers listen to CPU diagnostic interrupt Organization Blocks (OB82 for diagnostic alarms, OB83 for module insertion/removal, OB85 for priority class errors, OB86 for rack failure).

  • When an ET 200 analog card detects a wire break (current < 3.6 mA) or power supply failure, the module driver captures the diagnostic telegram and signals the channel driver. The channel driver immediately sets Bad = 1 and Quality Code = 16#00 (Bad).

  • If I/O were wired directly to a valve block, the valve block would receive raw zero without knowing whether the tank is empty or the sensor cable is severed!

Quality Codes and Signal Status Evaluation (IEEE 754 Floating Point with Quality Byte)

In the PCS 7 Advanced Process Library (APL), analog values are not passed as raw numbers; they are passed as structured data types comprising an IEEE 754 floating-point value and an 8-bit Quality Code (ST):

  • 16#80 (Good): Valid process value; transmitter is healthy and operating within calibrated boundaries.

  • 16#60 (Simulation): Simulated value; an engineer has placed the channel driver or technological block into manual simulation mode.

  • 16#00 (Bad): Hardware failure, open loop, short circuit, or module missing.

  • Technological blocks (PIDConL, MonAnL) evaluate this quality byte. If ST = 16#00, a PID controller automatically sheds from Auto to Manual mode to prevent runaway integral windup, safeguarding plant equipment.

Simulation Modes, Substitute Values, and Commissioning Overrides

Channel drivers provide indispensable tools for commissioning and instrument maintenance:

  • SimOn (Simulation Enable): Allows engineers during Factory Acceptance Testing (FAT) to force input values at parameter SimPV_In without physical I/O cards connected.

  • SubsPV_In (Substitute Value): When a hardware fault occurs (Bad = 1), the channel driver can be configured to hold the last valid value (Feature.Bit28) or output a pre-defined safe substitute value (SubsPV_In), allowing critical processes to shut down safely.

Comparative Architecture Matrix: Direct I/O Wiring vs Standard Channel Drivers

The following table compares direct peripheral addressing against standard PCS 7 channel drivers:

Operational AttributeDirect I/O Peripheral WiringPCS 7 Channel Drivers (APL)Hardware Fault DetectionNone (CPU receives 0 or frozen bits)Immediate (Bad = 1, OB82 diagnostic interrupt)Control System Fault (CSF)Cannot generate automated CSF alarmsAutomatically triggers CSF on technological faceplateQuality Code SupportNone (Raw primitive types)Full APL Quality Code byte (16#80, 16#60, 16#00)Commissioning SimulationRequires overriding physical memoryClean software simulation (SimOn, SimPV_In)Hardware Relocation ImpactMust update dozens of block pin connectionsUpdate single channel driver input pin onlyDriver Generator SupportIncompatible100% Automated by Generate Module Drivers

Step-by-Step Procedure to Implement Channel Drivers and Connect CSF

Follow this standard engineering workflow to connect field I/O via channel drivers in CFC:

  1. Place Channel Driver on CFC Sheet:
    - From the APL library, drag Pcs7DiIn (digital input) or Pcs7AnIn (analog input) onto the chart.

  2. Connect Physical Peripheral Address:
    - At input parameter PV_In, enter the symbolic name or raw peripheral address from HW Config (e.g., IW 512 or "TT_101_PV").

  3. Wire Signal to Technological Block:
    - Connect Pcs7AnIn.PV_Out to MonAnL.PV (or PIDConL.PV).
    - The connection automatically transfers both the Value and the ST (Signal Status byte).

  4. Wire Diagnostic Control System Fault (CSF):
    - Connect output pin Pcs7AnIn.Bad to the technological block's input CSF (Control System Fault).
    - When an open-wire occurs, Bad = 1 activates CSF = 1, triggering an immediate 'Control system fault' alarm in WinCC.

  5. Compile with Module Drivers Enabled:
    - In CFC, select CFC > Compile > Entire program.
    - In the compilation dialog, ensure the checkbox 'Generate module drivers' is strictly checked.
    - Click OK to generate the underlying diagnostic call hierarchy.

Verification

Verify channel driver diagnostic operation through these validation checks:

  1. In CFC Test Mode (Ctrl+T), monitor Pcs7AnIn. Verify that normal 4–20 mA signals display Bad = 0 and PV_Out.ST = 16#80.
  2. Disconnect the physical field wire on the analog input channel in the field cabinet.
  3. Verify that the ET 200 module's SF (System Fault) LED illuminates.
  4. In CFC, confirm that Pcs7AnIn.Bad transitions to 1 and PV_Out.ST drops to 16#00 within 100 ms.
  5. In WinCC OS Runtime, verify that the technological faceplate displays a yellow diagnostic symbol and generates a 'Control System Fault' alarm.

Limitations and Operational Precautions

  • Symbolic Table Requirement: For the Driver Generator to link channel drivers automatically, the peripheral I/O addresses must be defined in the Step 7 Symbol Table or assigned symbolic names directly in HW Config.
  • HART Variables: Standard Pcs7AnIn handles the primary 4–20 mA cyclic value. To read secondary/tertiary dynamic HART variables (SV, TV, QV), deploy the specialized APL HART driver block FbAnIn.
  • CPU Scan Load: While channel drivers introduce slight CPU instruction overhead, the diagnostic benefits far outweigh the minor processing cost.

Engineer FAQ

Can I connect Pcs7DiIn to multiple technological blocks?

Yes. The output PV_Out of a single channel driver can be interconnected to as many downstream logic blocks as necessary.

What is the difference between Pcs7AnIn and FbAnIn?

Pcs7AnIn is used for standard central or distributed ET 200 analog I/O modules. FbAnIn is used for fieldbus devices connected via PROFIBUS PA or Foundation Fieldbus, supporting extended device diagnostic status.

Why is Bad not setting to 1 when I disconnect a digital input wire?

Standard digital input modules cannot detect open wires unless they are specialized high-feature diagnostic digital input cards (e.g., NAMUR input modules or DI 8x24VDC High Feature with wire break monitoring enabled in HW Config).

What happens if I forget to check 'Generate module drivers' during compilation?

The channel driver will not receive diagnostic interrupt tokens from OB82/OB86. If a hardware fault occurs, the driver will remain unaware, leaving Bad = 0.

Can I use channel drivers for internal software calculation tags?

No. Channel drivers are designed exclusively for physical peripheral I/O addresses (IW, QW, IB, QB). For internal software signals, connect blocks directly.

Technical References

Related Articles

Related Tags

  • Channel Drivers
  • Pcs7DiIn
  • Pcs7AnIn
  • Hardware Diagnostics
  • CSF
  • Quality Code
  • APL
6 respuestas