SCADA standards

Hi guys,

I have tried getting answers from people on this topic before unsuccessfully.

I'd really appreciate getting as much feedback from different people as possible on this. I will start first. In my previous employment I always worked for consultants or contractors. We would do PLC and HMI programming for various water/wastewater facilities in the US and Canada. This involved a number of different platforms (GE, AB, Siemens, SCADAPack, etc). The program structure we were to follow (that is the City's/county's standards) changed very little from place to place. They all also had a standard by which the tags could be named. For example they would break it out into 5 or 6 fragments. the first fragment is the location, fragment 2 major equipment, fragment 3 minor equipment, etc... then they would give you what each fragment was allowed to be. For instance in one city, a low lift pump was LLP, and a high level float is ALMHI. Some of them even used ISA standards for their tagging, and customised it to include everything that's required in their facilities. Can you guys please tell me what percentage of end users define your standard PLC program, HMI screens, and tagging system. And which percent just lets you go wild. And what do you do for the ones that DO let you go wild? do you have your own standards? I am now an employee for the municipality in my area, and one of the major tasks I have is to take care of the standards, continue to improve them, etc. I'm shocked by what I'm reading here with everyone just making things up as they go along because I didn't know this is how things were done outside of my world.

We always use ISA S5.1 unless our client tell us to use his standard. The client is always right!!!

at least your municipality has some standard. Many smaller councils here in NZ have no standard, and no one to even enforce one if they did. It results in a big ol' mess, with 100 pump stations all looking / working a little (or a lot!) differently.

The tag naming structure you mention is fairly common for bigger plants. For the small councils I deal with, my normal tag naming structure looks something like S06_Pump1_Running where that tag would relate to outstation 6, Pump 1, Running feedback. That's fine when it's a 2 pump PS and there are maybe 25 tags for the entire site. The guys that use the SCADA in these places often struggle to get their heads around naming conventions like 01-05-PMP-145. They tend to be ex plumbers and drainlayers - computers are scary things they wish to hit with a wrench. I try to make it possible for them to interpret trends without needing the PIDs to find out what the tag name relates to.

As NoNuke said, the client is always right... unless they don't know what they want, in which case I'd look at what they have existing, and try and match to that.

I work at a coal fired power plant - We have a standard but it isnt as well-developed as some (there is a contstant, background push from external engineers to conform to a "company" standard, but that never seems to work perfectly- well but not perfectly).

my last job was (as an OEM) putting large conveyor systems into warehouses - we had our own standard becuase we were always the largest/most expensive system in the place and only 1 customer fought back against that (you can guess their name, it was a large, Arkansas-based retialler ...and the place was normally a new building to begin with. The customer's locations were so geographically varied that there was little benefit to uniformity across locations (ie: they were never going to share maintenance techs...)

On this board, there are a lot of small/single-machine controls guys - and if its a single machine tool, or a small standalone application then there is little motivation to adhere to some kind of standard - if the process only consumes 4 or 5 "pages" of logic (and the customer isnt paying for adherence to a standard...) and the deadline is yesterday - then I can understand why naming conventions go by the wayside.

its not ideal - but I am not shocked to see it.
-John

I've been involved in several hundred projects, most of them municipal. I didn't usually do the SCADA, but usually had to interface with it. I did have local HMI touchscreens on most.

I would say that less than 10% of municipalities had their own written standards for tags, colors, data formats, etc. This includes either their "own" or a third party standard they referenced. Some of the larger engineering consulting firms have standars. In my expereince the firm's standards are generally so complex, arcane, and separated from practice that they cause more time waste than they ever save by enforcing uniformity.

My experience is that the actual tag structure makes little difference to owners. Very few do more tham minor changes to displays and occassionally add a tag for new equipment. The benefit of a logical structure for tags is for the integration company programmer at the next major plant upgrade. The structure doesn't matter as long as it is logical and DOCUMENTED.

The real standard need is for units of display and trend formats. Establish alarm colors - Red severe, amber warning, grey not active, for example. The Red/Green = run is always a pain in the toosh. Units of measure for process data should be defined to meet operator needs. In Canada, for example, I don't care what the official policy is, many operators still think in imperial units for some parameters. I've done screens with a mix of imperial and metric units, at the operators request. It's there system to use every day - meet their needs.

If you are writing a standard, keep it simple. Don't try to cover every contingency. Work with the operators.

standards

As a Process Engineer for a major Florida water/wastewater municipality (26 years) we realized seven years ago we HAD to come up with standard for graphics, tags, colors, etc. We were dealing with so many consultants and contractors, that as we were trying to merge older systems into one or two HMIs, the tag names especially were getting cumbersome and confusing. No discredit to them, but it seemed that if left to their own, each contractor or consultant wanted to do our project the same way they did the last one (pretty evident when you see cut and paste errors that mention the last client's plants). We now have a 25 page document that covers HMI standards (colors, look and feel of graphics pages) and a 18 page document covering variable tag names. (excerpt below)
General format: ABCD_DEFG1234(A)
ABCD= Location (Which plant, and area of plant)
DEFG= Equip. type (MOTR, PUMP, PIRX-for instruments, we keep with ISA conventions as much as possible)
1234= LoopNumber (fromP&IDdrawings)
(A)= Optional Suffix (rarely used)
This is a Fixed width tag, any unused postions are padded with Xs. A Flow transmitter in the GTL plant might appear as: GTLP_FITX0013.
This has paid dividends as our plant HMI database is editable in Excel - so it is very easy to use the Sort or Filter commands to group or select tags of intrest. We spent months hammering out this format, and while it may be a bit cryptic, it works for us.
Now we send the contractor the two documents at the start of the project (and/or included it in the bid documents) and it heads off lots of questions from their Controls engineer.

This is what we do as well. I would say 20-30$ of end users that I have met have some sort of standard. It's a shame really. Mostly it's because they don't have anyone on staff to help with verification.

Tag names get way too long and convoluted. I just do what I want. If I had to work with tag based programming and those huge long tags the price would go up substantially.
Fortunately I use Omron PLCs and do not have to use tag based programming - I can just type in the I/O numbers so convoluted tags would probably not bother me much with Omron as I would not have to use them - just spend a month typing them up! That would add to the price too!
With SCADA I normally use Citect and each controller is defined of course.
For Gen5 controller I would start my digitals at DIG1 and my analogues at AN1 and so on.