Ideal PLC Programming Language and Software

Hi Michael,

I understand your plea for openness. One of the underlying assumptions in your plea is that open standards will be used by people with good intentions. It is an unfortunate fact of life that some people in this world don't have good intentions. How important is it for us to allow anyone with a modicum of knowledge to open a floodgate on a large dam, or perhaps manipulate an important valve in a city power plant? Some actions must be difficult to accomplish by the inherent design of the system. Building that security into an open system is a double edged sword. The open standard allows the entire world to find your security holes and therefore potentially allow you to fix them faster, but it allows the entire world to exploit them too.

Ken Stewart

The only thing PLC Open needs to address our needs is obvious and totally lacking. That is: An interest in being truly Open. They want to be the single entity to _control_ the "openness".

That is, also obviously, exactly the same as a single company maintaining control if the motives are the same, which it seems they are. The ideas of maintaining absolute control and opening something are contradictory and mutually exclusive. That's why every automation entity I've seen with OPEN in it's name can safely be taken to mean the opposite. That's not to say that even industry consortia could not actually Open something, merely that, so far, it is _not_ their intent. To understand their intent is reasonably easy, simply follow what you have to do to implement.

The licensing and compliance requirements are, the epitome of closed and make the use of Open in the name unethical and misleading at best. And it is ridiculous to call anything that depends on patented hardware or software Open. Or closed or single sourced software. To use the word Open as a marketing gimmick for these is fraudulent.

The most "open" thing I've seen so far is modbus.org and they are still gingerly feeling their way along. I have to do some silly clickthroughs, but I can actually read the specs and write an implementation for any hardware without their blessing and with some small confidence I won't get a cease and desist order for my effort. Not really Open, but enough to be useful. The others, IMHO, cross over the line as deliberately misusing the word Open. Not a popular view with the vendors perhaps, but it is eminently defensible. They should accept it as input from someone who has experience striving to achieve openness and maximize utility to the public.

Regards
cww

Hogwash!
The worst security problems in the world are on closed systems. High security systems are auditable.

Regards
cww

In reply to Ken Stewart: Your comment is far off track for two reasons. One reason is that we are talking about the process used to discuss standardising the programming languages used to program PLCs. The connection between this and implementing the security in a process plant is not apparent to me.

Secondly, you are talking about "security by obscurity". You can look up details of this concept quite readily, but you will find that it is considered to be completely ineffective. Proper security systems do not depend upon secret protocols or algorithms. You will find that genuine modern computer security systems depend upon methods are are published, publicly available, and open for review.

Michael..
I would suggest that the world of automation, being a very small cog in a big wheel, has a heavy support load, as well as big development costs which need to be funded. Thus the cost of most things..

While the 'community' may want to have openness, they are not willing to participate at the cost of business.

Thus the lack of any significant progress on the sharing of program structures from hardware vendor to hardware vendor .. IMHO - it will never
happen

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Control Design www[.]controldesignmag.com
Manufacturing Automation www[.]automationmag.com

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0
705.739.7155 Cell # 705.725.3579

Michael,

Here is my concern: where is the audit log? If someone breaks into a computer system and steals information or perhaps alters data, then that act is traceable. The caveat is that the wrongful act is traceable only on secure systems. Where is the audit log in a PLC? It doesn't exist. It doesn't even meet class D security standards (Orange Book, 1986).

If you have any illusions about secure operating systems, contact sources who monitor that stuff on a daily basis (McAfee, Symantec, SANS Institute, NIST, etc). If someone breaks into a PLC and causes damage, how do we track that? There are two goals in tracking intrusion. One goal is to punish the guilty; the other goal is learn from our mistakes in publishing faulty standards. My goal is the latter.

Ken Stewart

Great dialog guys. Open is as Open does...

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Ken - you raise an interesting point... I have wondered if the IEC-61131 'standard' should be a standard at all... but more a guideline.

It offers little from a standards point of view, but as a guideline that a vendors software can follow - there's a good fit.

The extensibility of the 'standard' and closed-door politics of vendors fails the user. Inherently it becomes closed again.

Things that make you go ummmmmmmmmmmmmm....

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Control Design www[.]controldesignmag.com
Manufacturing Automation www[.]automationmag.com

In reply to Ken Stewart: I will repeat again, "security by obscurity" doesn't work. You will not find any proper modern security system that relies on it. "Faulty standards" are typically the result of incorporating proprietary security systems into a standard.

The reason why some proprietary security systems depend upon secret algorithms isn't to protect them from "hackers". It is to protect the companies which sell them from customers finding out how weak and shoddy they are.

Audit logs have nothing to do with security algorithms. They are used to find unsuccessful attempts at break-in, or break-ins by amateurs. Once a serious hacker has broken in, they would normally alter the logs so they leave no trace.

Finally, we are talking about open programming language standards. If you are suggesting that we should have a programming language standard that virtually nobody has seen, I would have to say that the IEC and PLCOpen have already beat you to this goal.

In reply to Jeremy Pollard: I think we need to keep in mind what we are talking about here. We are talking about the process used to develop a better defined language standard. That doesn't involve actual product development or support.

I mentioned how things are done openly in many parts of the computer software world as an example of how this can occur. Yes, open collaboration can extend to the actual products as well, but that is a different story. A lot of discussion is actually centred around how existing systems should change in order to work together better. There is no reason why this can't happen with PLC standards as well.

I have given some suggestions in previous messages on how an open discussion could be conducted, so I won't go over that ground again. However, I would like to take the opportunity to point out that one of the major advantages of an open process is that it tends to take much of the market politics out of the discussion so that it can concentrate on the technical merits. When everyone can a party being obstructive for no good reason, it tends to cause the participants to modify their behaviour for the better.

As for whether the vendors *want* any progress in this field, well I would have to agree that you are likely correct on this for the larger ones at least. For the smaller vendors, they have more to gain than lose from this, so I don't see this as being a completely lost cause.

I will point out that in the computer world, large vendors such as Microsoft or Oracle can be just as obstructive about standards as any of the major automation vendors. That doesn't stop the rest of the industry from working together and making progress though.

In reply to Curt Wuollet: It would be interesting to see if we can compile a list of automation organisations that use the term "open" in either their name or their self-description. Here's my list:

PLCOpen - We've discussed this here.

OPC - They claim "OPC is open connectivity via open standards." Specifications are available to members only.

If we look at the major Ethernet based industrial protocols:

ODVA (Open Device Net Vendors Association) - Covers Devicenet, Ethernet/IP, CompoNet. You must be a paid-up member of the organisation to use the specs.

PI (Profibus and Profinet) - They claim "Profinet is open and non-proprietary, and may be freely used by anyone, even non-PI companies". However, all the specification documents are restricted to members only.

EtherCAT - They claim "EtherCAT is the open real-time Ethernet network". Specifications are available to members only.

PowerLink - "The open association in the field of deterministic real-time ethernet". They claim "ETHERNET Powerlink is an open protocol. It can be used by anybody without license costs or obligations." Specs are 250 EUR for non-members, but there don't seem to be any obvious restrictions (I haven't read the fine print though).

Modbus-IDA - You mention these as being the most "open" of any you have dealt with. The specs are readily available, as most people are aware.

So, most organisations seem to believe that "open" means "keep out." The exceptions seem to be Modbus and perhaps PowerLink. Does anyone have any other examples they would like to mention?

Well done Michael. We will add to the list... just having my Wheaties.

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

This reminds me of a few years ago when I had an idea to develop some simple products using a popular motion bus standard. If I recall correctly, the silicon was available at a reasonable price from a third party. The problem was that the specifications and certification process made the cost of developing a prototype way too costly for a hobby business. I couldn't have made my money back unless I charged huge amounts for the product, which of course I was trying to avoid.

Bill

There is no membership cost. A membership is required to get detailed specs for EtherCAT - necessary to manage compatibility. The ETG (EtherCAT Technology Group) is huge, by far the largest of its kind.

If any readers are at the Hannover fair next week, check out the EtherCAT booth. The performance and number of interoperating devices is far beyond anything you can imagine.

Robert B. Trask, PE
Los Angeles, CA

In reply to Robert B. Trask, PE: Compatibility is something that you would normally handle through trademark. That is, permission to use a trademark
name or logo (e.g. EtherCAT) would normally depend upon having that product pass a conformance test. Restricting availability of specifications does
nothing to manage compatibility - that is just a form of "security by obscurity".

The EtherCAT organisation also claims their network is covered by patents, although they do not specify what those patents might be.

I would suggest Michael, that due to the low volume in our biz, that smaller firms do not have the resources to carve the future. They may want to, but the big guns have much of the influence. In conversations I have had with smaller vendors, they are fighting to keep moving forward. Open source would be wonderful for them since it would improve their ability to make dough. But won't happen.

And a GM or someone of considerable clout would have to champion the cause - they did that with ODVA and Devicenet, and Controlnet. They tried to do it with IEC, and failed.

It has been abandoned as a cause.

Good effort tho!!

Cheers from: Jeremy Pollard, CET The Caring Canuckian! www[.]tsuonline.com

I've begun to hear some buzz about powerlink, I'll have to look into it if you can get any information for free :^).

The really galling part of all this is that these folks obviously know that customers want "open". They wouldn't throw the word around if they didn't think it valuable and something to be desired.

But, the founders list usually includes the stalwarts of proprietary excess and they clearly don't want to actually, really, open anything. I don't have a philosophical problem with that, I guess, they can run their businesses as they see fit. It causes huge numbers of practical problems, but they can be judged by that. My issue is that they intend to fool people into believing that their stuff is now Open and quite often succeed. I can't count the number of
times someone has called Windows open or told me that they are using OpenXXX or XXXOpen and asked
why they can't simply hook things together. And their anger is totally misdirected when you acquaint them with reality.

I really try not to waste time with the deluded anymore. It's like teaching a pig to sing. It
wastes your time and _really_ annoys the pig. The only thing that seems to work is simply to show what can be done with a truly Open system and then explain what you have to buy, license, and track and who you are completely dependent on, to do it with proprietary products if it can be done at all. People will accept the systems that let you do the job if you let Open sell itself.

It is one of my most puzzling questions why people so fiercely defend their malefactors.

Regards
cww

What we really need is for a couple dozen large automation users to get together and say they simply won't buy system that are crippled by incompatibility and proprietary excess. They don't need to specify what they will buy, that gets to be a nightmare and a path to failure.

They should simply state what they expect and let the vendors sort it out. It could be a simple test. I can put any PLC in this spot and it must run these programs without change and any PLCs A and B must connect to this ordinary Ethernet switch, and A and B must communicate and exchange these data. Simply what people might reasonably expect from all the advertising BS they've thrown around.

This is exactly what they are afraid of.

Regards
cww

Certain companies did that in the early days. OMAC was formed... and is still active, especially in the packaging arena. Normal control doesn't
benefit from the same involvement.

Ken Crater - host of this list - had a lab start up to test compatibility between devices, who SAY they are compatible. It's not around anymore...

Seems like it's Don't Care thing again...

Associations like PLCopen should provide the compatibility testing (as they do for the compliance levels), but who really cares if a product is IEC compliant?

You can't move the code anyway, and the interface is different albeit more the same than Rockwell vs. GE.

More importantly - does Siemens ST work in Rockwell's ControlLogix platform? i.e. copy and paste...

Will never get consensus or anyone to champion the fight... but the results of compatibility is what all are looking for.

I suggested such a task force for PLCopen in 2002. Wonder what people are afraid of?

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Control Design www[.]controldesignmag.com
Manufacturing Automation www[.]automationmag.com
Supporting Cystic Fibrosis www[.]theoryanproject.org

In reply to Curt Wuollet: From what little I have read about Powerlink, it seems to be mainly oriented towards motion control (servos and VSDs). It does do digital and analogue I/O as well, but the main emphasis is motion control.

Powerlink supposedly does real time multi-axis coordinated motion control using standard unmodified Ethernet. I imagine that to do this though, you would need to be working with an RTOS that is capable of keeping up with this. It can't do this with as many axes as Profinet (which doesn't use standard Ethernet for this), but the range it is capable of would probably cover 99% of all real world applications (and 100% of any that I have dealt with). They are apparently working on a new version that will incorporate hardware timing to extend the capabilities in this area (hopefully this will remain an optional feature).

Ethernet-Powerlink seems to be cooperating with CAN-Open, and it appears that Powerlink will be the Ethenet network of choice for many current CAN-Open vendors.

If you wish to talk to the Powerlink people, you might discuss if it would be possible for you to write a GPL'd driver (or module or whatever you want to call it) that is intended for people who want to do PC based control with servo drives (as opposed to deeply embedded applications which link multiple drives together). In this case, you many need only a small part of the spec.

Another party you might want to talk to is Baldor. The "technical specs" document for their "MicroFlex e100 ETHERNET Powerlink AC Servo Drive" has a fairly good overview of Powerlink. Baldor also has "Active-X" controls which are intended to allow PC applications to talk to the drives to perform certain simple actions. I don't know if the protocol in this case is based on Powerlink, or if it is a separate Baldor-only protocol.