Advantages of the Ovation DCS Extract

Demonstrating Advantages of the Ovation DCS to your PLC based Customers Extract

Provide customer some examples to demonstrate how savings can be realized by using Emerson’s DCS workflow, when compared with a PLC/HMI (SCADA) system. This information has been compiled from implementation expertise of DCS engineers, end-user control engineers and systems integrators who actively implement both types of control solutions based on application requirement and user preferences.

Though a PLC/SCADA system may have all or part of the following list of independent and manually coordinated databases.

• Each controller and its associated I/O
• Alarm management
• Batch/recipe and PLI
• Redundancy at all levels
• Historian
• Asset optimization
• Fieldbus device management

Each of these databases must be manually synchronized for the whole system to function correctly. That is acceptable immediately after initial system development. However, it becomes an unnecessary complication when changes are being implemented in on-going system tuning and further changes made as a result of continuous improvement programs.

Making changes
Every time a change is made in one database, the others usually need to be updated to reflect that change. For example, when an I/O point and some control logic are added there may be a need to change or add a SCADA element, the historian and the alarm database. This will require the plant engineer to make these changes in each of these databases, not just one – and get it right.
In another scenario, a change may be made in an alarm setting in a control loop. In a PLC implementation there is no automatic connection between the PLC and the SCADA/ HMI. This can become a problem during startup of a new application, where alarm limits are being constantly tweaked in the controller to work out the process, while trying to keep the alarm management and HMI applications up to date with the changes and also being useful to the operator.

Structure this explanation along a generic project development sequence of tasks:

Step 1: System design
PLC/ SCADA control engineers must map out system integration between HMI, alarming, controller communications and multiple controllers for every new project. Control addresses (tags) must be manually mapped in engineering documents to the rest of the system. This manual process is time consuming and error prone. Engineers also have to learn multiple software tools, which can often take weeks of time.
DCS approach: As control logic is designed, alarming, HMI and system communications are automatically configured. One software configuration tool is used to set up one database used by all system components. As the control engineer designs the control logic, the rest of the system falls into place. The simplicity of this approach allows engineers to understand this environment in a matter of a few days. Potential savings of 15-25% depending on how much HMI and alarming is being designed into the system.

Step 2: Programming
PLC/ SCADA control logic, alarming, system communications and HMI are programmed independently. Control engineers are responsible for the integration/ linking of multiple databases to create the system. Items to be manually duplicated in every element of the system include: scalability data, alarm levels, and Tag locations (addresses). Only basic control is available. Extensions in functionality need to be created on a per application basis (e.g. feed forward, tracking, self-tuning, alarming). This approach leads to non-standard applications, which are tedious to operate and maintain. Redundancy is rarely used with PLCs. One reason is the difficulty in setting it up and managing meaningful redundancy for the application.

The DCS approach: When control logic is developed, HMI faceplates, alarms and system communications are automatically configured. Faceplates automatically appear using the same alarm levels and scalability set up in the control logic. These critical data elements are only set up once in the system. This is analogous to having your calendars on your desktop and phone automatically sync vs. having to retype every appointment in both devices. People who try to keep two calendars in sync manually find it takes twice the time and the calendars are rarely ever in sync. Redundancy is set up in software quickly and easily, nearly with a click of a button. Potential savings of 15-35%

Step 3: Commissioning and start-up
Testing a PLC/ HMI system is normally conducted on the job site after all of the wiring is completed and the production manager is asking “why is the system not running yet?” Off line simulation is possible, but this takes an extensive effort of programming to write code which will simulates the application you are controlling. Owing to the high cost and complex programming, this is rarely done.

DCS benefits: Process control systems come with the ability to automatically simulate the process based on the logic, HMI and alarms that are going to be used by the operator at the plant. This saves significant time on-site since the programming has already been tested before the wiring is begun. Potential savings are 10-20% depending on the complexity of the startup and commissioning.

Step 4: Troubleshooting
PLC/ SCADA offers powerful troubleshooting tools for use if the controls engineer programs them into the system. For example, if an input or output is connected to the system, the control logic will be programmed into utilizing the control point, but when this is updated, did the data get linked to the correct HMI? Have alarms been set up to alert operators of problems? Are these points being communicated to the other controllers? Programming logic is rarely exposed to the operator since it is in a different software tool and not intuitive for an operator to understand.

The DCS approach: All information is automatically available to the operator based on the logic being executed in the controllers. This greatly reduces the time it takes to identify the issues and get your facility up and running again. The operator also has access to view the graphical function blocks as they run to see what is working and not (read only). Root Cause Analysis is standard. Field device diagnostics (HART and fieldbus) are available from the operator console. Potential savings of 10-40% (This varies greatly based on the time spent developing HMI and alarming, and keeping the system up to date.)

Step 5: The ability to change to meet process requirements
PLC/ SCADA: Changing the control logic to meet new application requirements is relatively easy. The challenge comes with additional requirements to integrate the new functionality to the operator stations. Also, documentation should be developed for every change. This does not happen as frequently as it should. If you were to change an input point to a new address or tag, that change must be manually propagated throughout the system.

The DCS approach: Adding or changing logic in the system is also easy. In many cases even easier to change logic with built in and custom libraries of code. When changes are made, the data entered into the control logic is automatically propagated to all aspects of the system. This means far less errors and the system has been changed with just a single change in the control logic. Potential savings of 20% on changes is not uncommon. This directly affects continuous improvement programs.

Step 6: Operator training
With PLC/ SCADA operator training is the responsibility of the developer of the application (typically the integrator on the project). There is no operator training from the vendor since every faceplate, HMI screen or alarm management function can be set up differently from the next. Even within a single application, operators could see different graphics for different areas of the application they are monitoring.

The DCS approach: Training for operators is available from the process control vendor. This is owing to the standardized way that information is presented to operators. This can significantly reduce operator training costs and quality due to the common and expected operator interface on any application, no matter who implements the system. This can commonly save 10% in training costs which can be magnified with the consistency found across operators and operator stations.

Step 7: System documentation
PLC/SCADA documentation is based on each part of the overall system. As each element is changed, documentation must be created to keep each document up to date. Again, this rarely happens, causing many issues with future changes and troubleshooting.

The DCS approach: As the control logic is changed, documentation for all aspects of the system is automatically created. This can save 30-40% depending on the nature of the system being put in place. These savings will directly minimize downtime recovery.

end