Six Decisions You Must Get Right Before Upgrading Your Automation System

There are six decisions you must get right before upgrading your automation system.

It doesn’t matter whether you are just upgrading equipment – like PLCs, RTUs, or HMIs – or upgrading larger automation systems – like compressor stations, pumping stations, or master station SCADA systems. We have found that automation upgrades often fail because buyers fail to make a few critical decisions early in the upgrade process.

This report identifies the critical decisions you must make early and correctly in order for your upgrade project to be cost effective, achieve your goals, and reduce the risk of incorrect startup and operation.

1. Decide on a clear purchasing and evaluation plan

Make sure you have a plan for identifying your needs, for documenting those needs, and for identifying the best vendors to approach for proposals and/or bids. Whether you hire a consultant or do this yourself, the purchasing and evaluation plan needs to include a time line for at least the following major tasks:
 

• Requirements development
• Procurement process
• Bidder selection process
• Bidder evaluation process
• Vendor award process
• Configuration
• Factory acceptance test
• Start-up

The plan should also indicate what percentage of each stage will be performed in-house and what percentage will be performed by the consultant, vendors, or others who will be involved.

This is your road map. As the philosopher once said, if you don’t know where you’re going, how will you know when you’ve arrived?

2. Decide early which stakeholders will be on the project team, and put only one person in charge

If your project’s scope warrants it, put in place a project team that participates in the upgrade process from the very beginning stages. This team should include all of the major stakeholders. Depending on the scope of the project, this might include field engineers, technicians, analysts, operations personnel, IT people, and management.

The field and operations people know what will and won’t work in the field. For a larger project, the IT people know the requirements of the back office or host system that might need to be interfaced with the field operations. And, management is best suited to keeping an eagle eye on the business goals and bottom line. Don’t wait to get these people on board. Get them involved from the beginning.

Once you have a project team, make sure that a single person is in charge. That person must have the authority to make decisions and to ensure that the system meets both the company’s technical and business goals – especially the company’s business goals. When one person has his or her reputation on the line, the project is more likely succeed.

3. Decide why you want to upgrade (your goals)

Why do you want to upgrade? If you can’t identify compelling reasons, don’t do it.

The absolute worst answer is “because it’s time.” Maybe your system’s components have reached end-of-life and are hard to repair, but they still work. Maybe they no longer represent cutting-edge technology. Maybe you’re tired of your competition whipping out photos of their shiny new system while you are embarrassed to show worn-out photos of your ancient, toothless system.

These are not usually compelling reasons to upgrade.

In fact, the only good reason to upgrade is because it achieves one or more tangible business goals. The exact goals will vary from company to company. What’s important is that those goals be identified and quantified, and that they become the most significant criteria in selecting a replacement system.

4. Decide what it will take to achieve your upgrade goals

Will a newer version of your current system achieve your stated goals? Do you need to replace all your hardware to achieve those goals? What new technologies can be applied to achieve the company’s business goals?

Typically, the answers to these and other questions end up in a specification that is ultimately put out for bid. And, just as typically, these documents are either too vague or too detailed for their own good.

Overly vague bid documents lead to overly vague bids. Telling vendors that you want to improve usability, maximize flexibility, and provide a platform for future expansion could mean just about anything. Vendors want to know exactly what you are trying to achieve so that they can provide you with a bid that will best meet your goals.

However, overly detailed bid documents can lead to overly costly projects – not bids, projects. If you tell vendors exactly how to do their job, they’ll give you low-ball bids that put all the risk back on you. Unless you know exactly what you want and how to go about getting it, you can’t think of everything this early in the upgrade process. If you try and you’re wrong, you’ll likely end up with low bids and lots of change orders. And you know what that means – project cost overruns.

What’s an engineer to do?

If you know exactly what you want, then you can write what we call a procedural specification that states exactly how you expect to accomplish your goals. Such a document is often loaded with lots of technical specifications for networks, timeouts, software, RTUs, PLCs, protocols, radios, etc. This will lock you into very narrow options. But if you’ve done your homework and know that this is the best way to go (i.e. no fear of change orders), then go for it.

But you may find that it’s best to write what we call a performance specification. The performance specification or request for proposal states exactly what you want to accomplish and asks vendors to propose ways to achieve those goals. You’ll get lots of ideas, and you may discover an approach worth considering that you would never have thought of otherwise. We have also found that taking this approach usually results in minimal (or no) change orders.

5. Decide what you want from your vendor before you start looking

Evaluating vendors and their responses to your questions should be a combination of art and science – a combination of corporate chemistry and bottom-line common sense.

Of course, cost is an easy factor to quantify. But it’s not so easy to compare less quantifiable factors like customer references and project methodology. It’s especially difficult calculating the effectiveness of a long-term relationship with the vendor.

But if your project is to succeed, those factors must be at the top of your list for consideration.

For example, if your project is large, you should consider examining each potential vendor’s project execution methodology. A documented project execution methodology can help ensure that all members of the team understand their role, understand company procedures, and understand the best way to accomplish major milestones.

How can you test that methodology short of actually hiring the vendor? First, ask each vendor staff member that you meet where they fit into the project lifecycle. Do they seem to act more like independent contractors or more like a team with a common sense of mission?

Next, talk to the vendor’s customers. Do their customers see tangible evidence that the vendor has a project execution plan? 

Does the vendor actually follow the plan, or is it just to impress prospects? Does the vendor provide written reports on a regular schedule? Are key vendor contacts available when needed? Can you talk to them and get straight answers? How is the after-project support? Go on site visits and see the installed systems first hand.

Similar questions can be applied to other intangible factors.

6. Decide what criteria will be used to judge the vendor and system

Very often we see very dense and complex vendor selection criteria. It seems that scoring bids will take a lot more work and time than it took to create the bid. You have to wonder how consistent scoring can be with such complex criteria. Most of it still boils down to a judgment call, and those judgments can’t possibly be consistent with so many criteria to consider.

If your selection criteria seems complex, then it’s probably not the fault of the selection criteria, but rather the specification and/or bid documents.

Make sure that all the information you ask from a vendor will be useful to you. Ask yourself how you plan to evaluate it, its significance to your goals, and whether or not it contributes any tangible value to your evaluation. You should also determine whether or not the information can be evaluated, and if so, whether or not you can easily and fairly compare vendor answers.

Source:-http://www.automation.com/library/articles-white-papers/general-automation-articles/six-decisions-you-must-get-right-before-upgrading-your-automation-system

Databases – The Perfect Complement to PLCs

By Steve Hechtman, President, Inductive Automation

PLCs? Okay, you’ve tackled PLCs and now you can program ‘em with one hand behind your back. So what’s next? What’s the next logical challenge? Think SQL and relational databases. Why? You’d be amazed the similarity. It’s the next logical progression.

You might ask how it is they’re even related. For one thing, relational databases can sort of be an extension of PLC memory. Live values can be mirrored there bi-directionally. Historical values and events can be recorded there as well. But operators and managers can interact with them too.

It’s been over twenty years of working, living, breathing and thinking PLCs, but over the last six years I’ve delved heavily into SQL and learned a lot about relational databases. I’ve discovered that working with SQL is remarkably similar to working with PLCs and ladder logic.

SQL has four basic commands and about a hundred different modifiers that can be applied to each. These can be applied in various ways to achieve all types of results. Here’s an example. Imagine effluent from a wastewater plant with its flow, PH and other things being monitored and logged. That’s what you typically see.

But now let’s associate other things with these, such as, discrete lab results, the name of the persons who did the lab work, the lab equipment IDs and calibration expiration dates, who was on shift at the time and the shift just prior, what their certification levels were, what chemicals where added and when, who the chemical suppliers were, how long the chemicals sat before use, and so forth ad infinitum. All of this becomes relational data, meaning that if it’s arranged properly in tables you can run SQL queries to obtain all types of interesting results. You might get insight into the most likely conditions which could result in an improper discharge so it can be prevented in the future.

In my explorations of SQL, I found myself looking at the layout of my tables and evaluating the pros and cons of each layout. I massaged them, turned them on their side, upside-down, and finally ended up with the most appropriate arrangement for my application. And similar to PLC programming, I explored innumerable what-if scenarios. I was struck by the amazing similarity in my approach to developing solutions for PLCs. This has been a lot of fun – in fact exhilarating – just like PLCs used to be. It’s the next logical progression you know.

SQL is a high level language that isn’t very hard to learn and you can be very clever with it. I prefer to think of it as a natural extension to my PLC programming skills. Now that you have the machinery running, what did it do? Furthermore, relational databases and SQL pull people and processes together. Machines don’t run alone.

They’re merely part of a containing process and that process was devised by people. SQL and relational databases form the bridge to integrate processes, machinery and people together. I don’t believe a COTS (commercial-off-the-shelf) package can do it any more than you could offer a COTS palletizer program and have it be of any use. It just doesn’t work that way. Every machine is different. And every business process is different.

That’s where the SQL comes in. It has to duplicate or augment existing process flows and these are intimately connected to the machinery. And that’s why the PLC programmer is best suited to implement solutions involving PLCs and relational databases.

So where do you start? I would suggest picking up a book at the bookstore like one of those dummies books. Then download and install the open-source MySQL database server along with the MySQL Administrator and Query Browser.

It only takes a few minutes to install and then start playing. You can read about a LEFT JOIN or INNER JOIN but typing one in and observing the results is worth about 1000 words. At the end of an evening you’ll probably be very excited with all of your new found knowledge and be thinking of endless ways to employ it in your own field of practice. Happy SQLing! 

Coder’s Corner: PLCopen Standards Architecture & Data Typing | Sofcon Training India Pvt Ltd

By Dr. Ken Ryan, Alexandria Technical College

Dr. Ken Ryan is a PLCopen board member and an instructor in the Center for Automation and Motion Control at Alexandria Technical College. He is the founder and director of the Manufacturing Automation Research Laboratory and directs the Automation Systems Integration program at the center.

This is the first in a series of articles focused on writing code using the IEC 61131-3 programming standard. The first few articles will focus on orientation to the architecture of the standard and the data typing conventions. After covering these, this series will explore code writing for a diverse field of application situations.

THE IEC 61131-3 SOFTWARE MODEL

Figure 1

The IEC 61131-3 standard has a hierarchal approach to programming structure. The software model in Figure 1 depicts the block diagram on this structure. Let’s decompose this structure from the top down.

Configuration:

At the top level of the software structure for any control application is the configuration. This is the “configuration” or the control architecture of the software defining the function of a particular PLC in a specific application. This PLC may have many processors and may be one of several used in an overall application such as a processing plant. We generally discuss one configuration as encompassing only one PLC but with PC-based control this may be extended to include one PC that may have the capability of several PLCs. A configuration may need to communicate with other configurations in the overall process using defined interfaces which provide access paths for communication functions. These must be formally specified using standard language elements.

Resource:

Beneath each configuration reside one or more resources. The resource supplies the support for program execution. This is defined by the standard as:

‘A resource corresponds to a “signal processing function” and its “man-machine interface” and “sensor and actuator interface” functions (if any) as defined in IEC 61131-3’.

An IEC program cannot execute unless loaded on a resource. A resource may be a runtime application existing in a controller that may exist in a PLC or on a PC. In fact, in many integrated development environments today, the runtime system can be used to simulate control program execution for development and debug purposes. In most cases a single configuration will contain a single resource but the standard provides for multiple resources in a single configuration. Figure 1 shows 2 resources under one configuration.

Task:

Tasks are the execution control mechanism for the resource. There may be no specifically defined task or multiple tasks defined for any given resource. If no task is declared the runtime software needs to have a specific program it recognizes for default execution. As you can see from Figure 1 tasks are able to call programs and function blocks. However, some implementations of the IEC 61131-3 standard limit tasks to calling programs only and not function blocks. Tasks have 3 attributes:

1.  Name

2.  Type – Continuous, Cyclic or Event-based

3.  Priority – 0 = Highest priority

The next article in this series will focus exclusively on tasks and their configuration and associations to programs and function blocks. For now we will continue our decomposition of the software model.

Program Organization Units:

The lower three levels of the software model are referred to collectively as Program Organization Units (POUs).

• Programs
• Function Blocks
• Functions

Programs:

A program, when used as a noun, refers to a software object that can incorporate or ‘invoke’ a number of function blocks or functions to perform the signal processing necessary to accomplish partial or complete control of a machine or process by a programmable controller system. This is usually done through the linking of several function blocks and the exchange of data through software connections created using variables. Instances (copies of a program can only be created at the resource level. Programs can read and write I/O data using global and directly represented variables. Programs can invoke and exchange data with other programs using resource-level global variables. Programs can exchange data with programs in other configurations using communication function blocks and via access paths.

Function Blocks:

The real workhorses of this hierarchal software structure are the function blocks. It is common to link function blocks both vertically (one function block extends another) or horizontally (one function block invokes another) in order to create a well structured control architecture. Function Blocks encapsulate both the data (as internal variables and the input and output variable that interface the function blocks to other software objects) and an encoded algorithm that determines the value of internal and output variables based on the current value of input and internal variables. The key differentiator between function blocks and functions is the retention of values in memory which is unique to function blocks and not an attribute of functions. Since a function block can have a defined state by virtue of its memory, its class description can be copied (instantiated) multiple times. One of the simplest examples of a function block is a timer. Once the class object “timer” is described multiple copies of the class can be instantiated (timer1, timer2, timer3… etc.) each having a unique state based on the value of its variables.

Functions:

The ‘lowest’ level of program organization unit it the function. A function is a software object which when invoked and supplied with a unique set of input variables will return a single value with the same name and of the same data type as those of the function. The sine qua non of a function is the behavior that returns the same value anytime the same input values are supplied. The best example of a function is the ADD function. Any time I supply 2 and 2 to the ADD function inputs I will receive a 4 as the return value. Since there is no other solution for 2+2 then there is no need to store information about the previous invocation of the ADD function (no instantiation) and thus no need for internal memory.

Access paths:

The method provided for exchange of data between different configurations is that of access paths. Access paths supply a named variable that through which a configuration can transfer data values to/from other remote configurations. The standard does not define the lower layer protocol to be used for this transfer but rather defines the creation of a construct (‘container’) in which the data can travel.

Global Variable:

Finally we come to the variables which are declared to be “visible” to all members of a specific level on the hierarchy. If a global variable is declared at the program level then all programs, function blocks and functions that are members of this program have access to this data. We say that the data is within their scope. Likewise, a global variable declared at the resource level will be available to ALL programs located on this resource.

Conclusion:

The IEC 61131-3 software model is modular and hierarchal. We have outlined its major components in this first tutorial. Next time we will look at details of the task mechanism. Later tutorials will focus on specifics of the POUs with emphasis on the differences between programs, function blocks and functions. Access paths will be the focus of another tutorial along with the concepts of data typing.

Source:-http://www.automation.com/library/articles-white-papers/programmable-control-plc-pac/coder146s-corner-plcopen-standards-architecture--data-typing