Open Control Effects on Industry Structure

M

Thread Starter

Michael Griffin

When this topic started, there was a brief discussion on what "open control" might look like, but it seemed to have petered out. I thought though to outline some ideas I've had as to what a control system based on "somewhat open" principles would mean for the structure of the automation components business.

I will use a hypothetical case to illustrate the points. Assume the application is a small, fully automated assembly machine. I would speculate that a system would look something like what I have listed below. Virtually everything I have listed already exists to some extent. It would however become the norm, rather than the exception.

- The I/O is separated from the PLC CPU. This assumes that *all* I/O is connected by some form of "fieldbus" or I/O network. The I/O market would be dominated by a few specialist companies selling commodity I/O. Competition would be based to a large extent on price for the most common types.

- Smaller I/O companies would exist to fill niche markets.

- The number of different "fieldbuses" or I/O networks would decline, as the less common varieties die out. If people are buying their I/O and CPUs separately, they will want the I/O network which is most widely available.

- Most PLC CPUs would be integrated into some form of MMI panel (likely a touch screen system). Many systems already use separate PLCs and MMI panels. If the I/O isn't directly connected to the CPU anymore, then there is no reason to put the CPU inside the control panel. This means the MMI panel and PLC markets would converge.

- "Soft logic" systems would predominate. It does not necessarily follow that this means "PC based control" though. It just means that the CPU (logic solving) hardware and software could be separated if the buyer wished. Alternate soft logic systems could be installed.

- Special soft logic systems would be directed at particular markets. There would even be standard packages available for particular common applications. Real time concerns could be addressed with real time operating systems.

- Price competition in the CPU market would mean that companies selling low end CPUs would have to look very hard at licensing costs for third party operating systems. This would mean either no operating system, or a cheap (or free) one. This would be transparent to the customer if the soft logic system is sold pre-installed in the CPU hardware.

- I/O would be more distributed than it is now and mounted directly in the machine. For pneumatically actuated devices, I/O nodes would consist of a valve node containing a single valve with sensor inputs integrated into it. E.g., a cylinder which requires a valve and two MRS switches would plug the hoses and wires into a single I/O node block. Larger cylinders could have this node block integrated into them (e.g., plug directly into the end cap). Manifolds may no longer exist except when dealing with large numbers of very small cylinders.
This means the pneumatic companies may dominate much of the I/O market since they would make the valve/sensor modules.

- Terminal blocks will largely disappear since the traditional I/O wiring will no longer exist. They will still be needed for power distribution, but the the overall terminal block market would be much smaller.

- Instrumentation will connect to the CPU via an I/O network or "fieldbus" instead of an analogue signal. Most of the existing market for intelligent signal conditions (e.g., ones with built in displays, limits, alarms, etc.) would disappear as this functionality is incorporated into the PLC software. The exception would be for the more sophisticated systems that need direct access to the instrument I/O (e.g., press force monitoring systems).

- With the PLC, I/O and most of the terminal blocks gone from the control panel, all that would be left in many cases is the disconnect and lock-out, power supplies, fusing, and the safety controller (which implements the safety interlocks). This means there may be a market for pre-assembled panels in standard sizes. You would order it according to desired voltage input and power supply size. You would install your own safety controller and make the external connections.

- Servo or stepper drives would co-operate with PLCs more closely. The higher level motion control programs could run in the PLC CPU along side the regular soft logic system (integrated together somehow), with just the lower level control logic running in the drive.


What is needed to make the above work is mainly a standard, open, universal I/O network. Everything else already exists in some form. The difference is more a matter of degree of emphasis rather than any new technology.
What I have suggested as being different though is how the business is split up. Traditional PLC manufacturers may not have the I/O market. The soft logic systems may be separated from the hardware. However, I suspect that most people will want to buy the latter two (soft logic and CPU) as a package.
Getting into the PLC business would be much easier though since a company wouldn't have to provide a range of I/O. They could just either private label third party I/O, or simply suggest that their customers buy the I/O from whomever they wish.

I think the above business implications are realistic. Does anyone have any comments?


--

************************
Michael Griffin
London, Ont. Canada
************************
 
C

Curt Wuollet

Hi Michael

Michael Griffin wrote:
>
> When this topic started, there was a brief discussion on what "open
control"
> might look like, but it seemed to have petered out. I thought though to
> outline some ideas I've had as to what a control system based on "somewhat
> open" principles would mean for the structure of the automation components
> business.
>
> I will use a hypothetical case to illustrate the points. Assume the
> application is a small, fully automated assembly machine. I would speculate
> that a system would look something like what I have listed below. Virtually
> everything I have listed already exists to some extent. It would however
> become the norm, rather than the exception.
>
> - The I/O is separated from the PLC CPU. This assumes that *all* I/O
is > connected by some form of "fieldbus" or I/O network. The I/O market would be
> dominated by a few specialist companies selling commodity I/O. Competition
> would be based to a large extent on price for the most common types.
>
> - Smaller I/O companies would exist to fill niche markets.
>
> - The number of different "fieldbuses" or I/O networks would decline,
as the
> less common varieties die out. If people are buying their I/O and CPUs
> separately, they will want the I/O network which is most widely available.
>
> - Most PLC CPUs would be integrated into some form of MMI panel
(likely a
> touch screen system). Many systems already use separate PLCs and MMI panels.
> If the I/O isn't directly connected to the CPU anymore, then there is no
> reason to put the CPU inside the control panel. This means the MMI panel and
> PLC markets would converge.

A PLC with no IO and capable of running interchangeable software begins looking exactly like the small SBC I'm using in my Open Hardware
project. I'm not sure at all that panel pcs are going to be the predominant model. There are still too many "headless" applications. Of course if the dominant OS requires graphics this may well come true. Since the display is the most costly component, I expect we will have both. Once
everything is on the network there is really no reason to integrate these. Present integration is driven by the (poor IMHO) choice of OS. If the machine needs a HMI, then integration makes sense. A PLC with networked IO and unbundled software is simply a generic SBC.


> - "Soft logic" systems would predominate. It does not necessarily
follow
> that this means "PC based control" though. It just means that the CPU (logic
> solving) hardware and software could be separated if the buyer wished.
> Alternate soft logic systems could be installed.
>
> - Special soft logic systems would be directed at particular markets.
There
> would even be standard packages available for particular common applications.
> Real time concerns could be addressed with real time operating systems.
>
> - Price competition in the CPU market would mean that companies
selling low
> end CPUs would have to look very hard at licensing costs for third party
> operating systems. This would mean either no operating system, or a cheap (or
> free) one. This would be transparent to the customer if the soft logic system
> is sold pre-installed in the CPU hardware.

And an absolute neccesity for this to happen. No one proprietary system will ever become universal enough to attract ports of competing logic
systems. It must be vendor blind and independent or competitors won't play. No commercial system will meet these criteria.

> - I/O would be more distributed than it is now and mounted directly
in the
> machine. For pneumatically actuated devices, I/O nodes would consist of a
> valve node containing a single valve with sensor inputs integrated into it.
> E.g., a cylinder which requires a valve and two MRS switches would plug the
> hoses and wires into a single I/O node block. Larger cylinders could have
> this node block integrated into them (e.g., plug directly into the end cap).
> Manifolds may no longer exist except when dealing with large numbers of very
> small cylinders.
> This means the pneumatic companies may dominate much of the I/O
market since
> they would make the valve/sensor modules.

This is going to require the most work. Getting a network stack on a sensor at anything like reasonable and competitive cost will need commodity silicon or a new type of ASIC that combines a very inexpensive cpu, it's resources and the network interface on the same die. I expect local IO will be important until this is accomplished. Some close cousins are available today. It doesn't take much for one point. The network is the problem.

> - Terminal blocks will largely disappear since the traditional I/O
wiring
> will no longer exist. They will still be needed for power distribution, but
> the the overall terminal block market would be much smaller.
>
> - Instrumentation will connect to the CPU via an I/O network or
"fieldbus"
> instead of an analogue signal. Most of the existing market for intelligent
> signal conditions (e.g., ones with built in displays, limits, alarms, etc.)
> would disappear as this functionality is incorporated into the PLC software.
> The exception would be for the more sophisticated systems that need direct
> access to the instrument I/O (e.g., press force monitoring systems).
>
> - With the PLC, I/O and most of the terminal blocks gone from the control
> panel, all that would be left in many cases is the disconnect and lock-out,
> power supplies, fusing, and the safety controller (which implements the
> safety interlocks). This means there may be a market for pre-assembled panels
> in standard sizes. You would order it according to desired voltage input and
> power supply size. You would install your own safety controller and make the
> external connections.
>
> - Servo or stepper drives would co-operate with PLCs more closely.
The
> higher level motion control programs could run in the PLC CPU along side the
> regular soft logic system (integrated together somehow), with just the lower
> level control logic running in the drive.
>
> What is needed to make the above work is mainly a standard, open,
universal
> I/O network. Everything else already exists in some form. The difference is
> more a matter of degree of emphasis rather than any new technology.
> What I have suggested as being different though is how the business is split
> up. Traditional PLC manufacturers may not have the I/O market. The soft logic
> systems may be separated from the hardware. However, I suspect that most
> people will want to buy the latter two (soft logic and CPU) as a package.
> Getting into the PLC business would be much easier though since a
company
> wouldn't have to provide a range of I/O. They could just either private label
> third party I/O, or simply suggest that their customers buy the I/O from
> whomever they wish.
>
> I think the above business implications are realistic. Does anyone
have any
> comments?

The single standard Open IO network will probably have to come from a totally independent group as well. One that answers most needs yet is simple enough for economical smart sensors to handle will have to be "forced" on the industry and be open everything to prevent proprietary extensions and a return to the same game. The part I'm grappling with is where the push is going to come from. It seems most folks here simply don't care enough to make this happen. And it has to come from the bottom up or outside. I have zero confidence in the vision of the corporations with vested interest in maintaining the status quo.

The divisions are about right. The current majors would have to become software houses and leave the hardware to companies that can survive with a commodity model. I think individual networked sensors are a ways off, but this industry is atypical in that there is much less pricing pressure. From the direction in the embedded market, I see little future for shrinkwrap software when cost becomes an issue and adequate Open alternatives exist.

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to
Linux.
 
B
How close a network can come to each and every device and still be practical application is part of the question Michael raises.

In the past, when I considered this question I always came to the point that Michael touched on. Every device requires power which has to be established in such a way that one device can fail or be removed without effecting other
devices.

From a practical plant viewpoint it would seem to me that if individual power points were still required for every device, then we may as well make them I/O points at the same time.

Actually this could be an advantage. A gateway of a number (say 12) of I/O could have common power delivered to it, distributed to devices through the 12 I/O via normal shielded pair. Thus, the gateway could contain a cpu and local control both analog and discrete. True distributed control.

Bob Pawley
250-493-6146
 
F
> This is going to require the most work. Getting a network stack on a
> sensor
> at anything like reasonable and competitive cost will need commodity
> silicon or a new type of ASIC that combines a very inexpensive cpu, it's
> resources and the network interface on the same die. I expect local IO
> will be important until this is accomplished. Some close cousins are
> available today. It doesn't take much for one point. The network is the
> problem.


Echelon created just that. The Neuron chip has:

1) 3 8 bit CPUs - One for the MAC layer of the protocol, one for the middle network layers and one for the application layer.
2) a complete peer-to-peer communication protocol optimized for control applications
3) an event driven operating system
4) I/O with built in I/O driver firmware
5) RAM, ROM and EEPROM
6) available from Toshiba and Cypress

I don't know the exact costs these days, but I believe in low volumes (depending on which chip configuration) it is less than $8 USD, much lower
in production volumes.
 
M

Michael Griffin

I mentioned the need for making I/O more distributed, perhaps even integrating the valve and sensor network node into the end of a pneumatic cylider.

On February 28, 2002 10:53 pm, Curt Wuollet wrote:
<clip>
> This is going to require the most work. Getting a network stack on a
> sensor
> at anything like reasonable and competitive cost will need commodity
> silicon or a new type of ASIC that combines a very inexpensive cpu, it's
> resources and the network interface on the same die. I expect local IO
> will be important until this is accomplished. Some close cousins are
> available today. It doesn't take much for one point. The network is the
> problem.
<clip>

We have ASI and Devicenet today. These are the sorts of I/O networks I had in mind (leaving aside the relative merits of either of these examples). They are intended to be simple and (relatively) inexpensive to use. While no doubt either (or both) of these examples could be improved upon technically, the general concept seems worth while.

I have noticed that in the types of applications I am familiar with, high capacity networks like Profibus don't do much to eliminate wiring clutter near the end device. Since the cost of a node is fairly high, you end up with a fairly large node which services a number of adjacent devices. You still have a block of inputs with individual sensor cables coming out, and a bank of valves with masses of hoses. This results in some rather congested machines.
I would like to attach a node containing a single valve and a pair of sensor inputs directly to the cylinder, or at least very close to it. (There is an ASI device meant for conveyor systems similar to this). This should eliminate a lot of the wiring and hoses.

What this means is that I don't think ethernet TCP/IP is the best solution for this sort of situation (at least not today). It works best when you have a lot of data in a few locations, as opposed to very small amounts of data in many low cost locations.

On the other hand, the last thing we need is a different kind of network for every application. There are companies developing products for other markets which are trying to come up with low cost networking methods based on common standards. The sort of solution I am looking for is more likely to be imported into industrial automation from the consumer market, than to be developed especially for industrial use.


--

************************
Michael Griffin
London, Ont. Canada
************************
 
C

Curt Wuollet

Sound great so far: I may do a small feasibility study to determine how Open the protocol and implementation are. I believe I looked at that a few years ago and found there were roadblocks. My criteria are fairly strict. I should be able to purchase purchase cards from at least two vendors and write and GPL a driver wothout legal encumberances. And it would greatly help if the proto is not controlled by a single entity or is defacto to the point where it can't be revved frequently simply for the purpose of selling hardware. Perhaps our LON fans can help out. If there's no downside, it would be a mystery why it's not more popular.


Regards

cww
 
C

Curt Wuollet

Hi Michael

Michael Griffin wrote:
>
> I mentioned the need for making I/O more distributed, perhaps even
> integrating the valve and sensor network node into the end of a pneumatic
> cylider.
>
> On February 28, 2002 10:53 pm, Curt Wuollet wrote:
> <clip>
> > This is going to require the most work. Getting a network stack on a
> > sensor
> > at anything like reasonable and competitive cost will need commodity
> > silicon or a new type of ASIC that combines a very inexpensive cpu, it's
> > resources and the network interface on the same die. I expect local IO
> > will be important until this is accomplished. Some close cousins are
> > available today. It doesn't take much for one point. The network is the
> > problem.
> <clip>
>
> We have ASI and Devicenet today. These are the sorts of I/O networks I had
> in mind (leaving aside the relative merits of either of these examples). They
> are intended to be simple and (relatively) inexpensive to use. While no doubt
> either (or both) of these examples could be improved upon technically,
> the general concept seems worth while.

There is still the problem of a microprocessor to run a loop even with simplest serial protocols. Don't get me wrong, I'm very much a proponent. I'm really surprised there aren't more folks working on an all-silicon solution. The one with the fewest external components needed is one that volumes can commoditize, And there's room for a chip almost anywhere. In the meantime, I think it rational to use what is commoditized already as automation volumes and lack of standardization make new designs pretty risky..

> I have noticed that in the types of applications I am familiar with, high
> capacity networks like Profibus don't do much to eliminate wiring clutter
> near the end device. Since the cost of a node is fairly high, you end up with
> a fairly large node which services a number of adjacent devices. You still
> have a block of inputs with individual sensor cables coming out, and a bank
> of valves with masses of hoses. This results in some rather congested
> machines.

Exactly.

> I would like to attach a node containing a single valve and a pair of sensor
> inputs directly to the cylinder, or at least very close to it. (There is an
> ASI device meant for conveyor systems similar to this). This should eliminate
> a lot of the wiring and hoses.

Yes, and be considerably simpler.

> What this means is that I don't think ethernet TCP/IP is the best solution
> for this sort of situation (at least not today). It works best when you have
> a lot of data in a few locations, as opposed to very small amounts of data in
> many low cost locations.

I agree that CAN or perhaps some yet unknown high speed serial transport may be better. CAN simply because it's doing this kind of thing in the real world or a high speed serial link because it can run on simpler silicon. The reason I think of Ethernet as an interim for sensors and a good backbone is that it's everyplace already and inarguably Open and Ethernet cards are $10.00 which gets us a lot closer a lot faster than anything else. I say CAN rather than DeviceNet because ODVA is dedicated to the old model where you would rather have control of a tiny market than compete in a vast market. The old model has failed, will fail, and is what has rendered fieldbus/distributed IO stillborn rather than the big moneymaker they were dreaming of. I agree that we certainly don't need more protos but we need one that's not already entrenched. I did check into LonTalk but, there are patents involved and that's an automatic turn-off for competitors.

> On the other hand, the last thing we need is a different kind of network for
> every application. There are companies developing products for other markets
> which are trying to come up with low cost networking methods based on common
> standards. The sort of solution I am looking for is more likely to be
> imported into industrial automation from the consumer market, than to be
> developed especially for industrial use.

That's what I'm thinking as well. It's a shame that the people with the experience can't see any farther than their bottom line and agree on just _one_ thing. They putzed around until Ethernet got drafted, Now they have just about rendered that useless following the old model. I'm getting to the point where I don't think even divine intervention could keep them from blasting their feet. Those who don't learn from history are doomed to repeat it. I would think they would be more than willing to trade guns for butter and find a way out of deadlock through a neutral intermediary.

Regards

cww
 
L

Lynn August Linse

The biggest "down-side" of the Echelon design is all of the Patents related to it.

As long as you just buy Neuron chips to put in your end-device product (ie: a temperature sensor or control point) you are home free. Echelon is happy - you are happy - customers are happy.

But what if you don't want to use a Neuron chip? Suppose you already have a 16-bit processor with special dual-port-memory features you need to use? You'd be violating many patents if you tried to make it talk to LON without a Neuron chip. So you can add a 2nd CPU (the Neuron chip + support ROM etc) to act as co-processor, but why should you? $8 is a pretty heavy price for an 8-bit CPU if it's only acting as a co-pro.

The other problem is if you what to create a "comm" type product - for example an Ethernet-to-LON gateway. Echelon already makes such a thing, but sells it for a pretty high price (over $1000?). We could make one like it for maybe a list of $295 or $345, but a quick scan through all the Patent documents implies we'd be in legal trouble for doing such a thing. There is complex wording which differentiates a final end product and an intermediate product, the first type being granted license and the second type NOT being granted license.

Lantronix is repeated asked for TCP<->LON products, and everytime Marketing gets design requests down to me, I just send them to the Echelon Patent documentation and say "If you can show that what you want is legal, I'll help ...". To me this would clearly be an intermediate product & thus not allowed.

If I'm wrong, I hope someone from Echelon can clear up this sticking point.

regards

Lynn August Linse, Senior IA Application Engineer
15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618
[email protected] www.lantronix.com
Tel: (949)300-6337 Fax: (949)453-7152

Get Plugged-In to the Lantronix quarterly solutions magazine
- subscribe today at www.lantronix.com/plugged-in
 
P

Peter Whalley

Hi Curt,

Gesytec have a range of LON based cards using Neuron chips that you may find of interest. They also have a Linux driver for these that "..may be distributed under the terms of the GNU Public License.." according to the readme. Have a look at:

"http://www.gesytec.de/englisch/index-e.htm":http://www.gesytec.de/englisch/index-e.htm

The LonTalk protocol has been very stable because it's locked into the silicon and is thus very difficult to change at least in a way that makes older product incompatible. It's also open to the extent that it's defined in the EIA709.1 standard.

There is a reference implementation of the protocol stack available in C source but the license terms are likely to be too onerous for most people.

Regards

Peter Whalley

Magenta Communications Pty Ltd

Melbourne, VIC, Australia

e-mail: peter*no-spam*@magentacomm.com.au
delete *no-spam* before sending
 
F
> From: "Lynn Linse" <[email protected]>
>
> > > From: "Fred Graham" <[email protected]>
> > >
> > > Echelon created just that. The Neuron chip ...
> >
> >
> > From: Curt Wuollet [mailto:[email protected]]
> >
> > Sound great so far: I may do a small feasibility study to
> > determine how Open the protocol and implementation are.
> > ...
> > If there's no downside, it would be a mystery why it's not more
> > popular.
>
> The biggest "down-side" of the Echelon design is all of the Patents
> related to it.

This is probably the biggest area of misinformation or misunderstanding. Yes there are patents on a number of Echelons products. But the protocol is an open EIA standard (EIA 709) and there are no royalty payments required.

> As long as you just buy Neuron chips to put in your end-device product
> (ie: a temperature sensor or control point) you are home free. Echelon
> is happy - you are happy - customers are happy.
>
> But what if you don't want to use a Neuron chip? Suppose you already
> have a 16-bit processor with special dual-port-memory features you need
> to use? You'd be violating many patents if you tried to make it talk to
> LON without a Neuron chip. So you can add a 2nd CPU (the Neuron chip +
> support ROM etc) to act as co-processor, but why should you? $8 is a
> pretty heavy price for an 8-bit CPU if it's only acting as a co-pro.

First, this is incorrect. You can get the spec from the EIA and implement the LonTalk protocol in your 16 bit processor and run the protocol natively on that processor. Or you can go to one of several companies who have made businesses out of porting the protocol to various processors. The only fee or money that is "required" is that every LonWorks device needs to have a unique 48 bit id associated with it, similiar to the MAC address on an Ethernet card. Those unique 48bit ids are administered by Echelon and there is a small fee (I don't recall how much but its in the order of pennies per id). Some people might object to that, but it is what it is. Echelon wants to insure that every device is unique and conforms to interoperability standards so that any LonWorks device is capable of communicating with any other LonWorks device. The $8 cost you mention was just a ballpark value I threw and is likely high and is definitely a price in very low volume.

> The other problem is if you what to create a "comm" type product - for
> example an Ethernet-to-LON gateway. Echelon already makes such a thing,
> but sells it for a pretty high price (over $1000?). We could make one
> like it for maybe a list of $295 or $345, but a quick scan through all
> the Patent documents implies we'd be in legal trouble for doing such a
> thing. There is complex wording which differentiates a final end product
> and an intermediate product, the first type being granted license and
> the second type NOT being granted license.

Echelon also has 2 other iLons (Ethernet/LonWorks) that have recently been
announced and those are at much lower costs with different sets of features. Whether or not the original iLon 1000 (under $1000 in moderate volume) is too expensive depends on what you need. The i.Lon 1000 is not only a LonWorks/Ethernet router (not gateway) but it also has a complete webserver built in with Flash memory to store the web pages. If you just need the router function without the webserver, then the i.Lon 10 is much lower in price.

As for designing your own, the specifications for creating a LonWorks/Ethernet router is in the LonMark Interoperability organization and any member of the LonMark organization can implement their own version - and there are several other companies besides Echelon who either have or are working on devices - without having to worry about any legal troubles. I am not sure what you are reading, but your information is wrong.

> Lantronix is repeated asked for TCP<->LON products, and everytime
> Marketing gets design requests down to me, I just send them to the
> Echelon Patent documentation and say "If you can show that what you want
> is legal, I'll help ...". To me this would clearly be an intermediate
> product & thus not allowed.
>
> If I'm wrong, I hope someone from Echelon can clear up this sticking
> point.

While I don't work for Echelon now, I did for 9 years and pretty familiar with their products. I know for a fact that you can port the protocol to your own processor (not trivial but doable), and you can design your own LonTalk/Ethernet router - all without running into any legal problems.

Now to be fair, Echelon does have some rather draconian sections in their license agreements. While you can do those things, you have to sign a no charge liscense. The intent of this is to insure that you make sure that whatever you create is interoperable with all of the other LonWorks devices and systems.

Hope this clarifies things a bit.

Regards,


Fred Graham
Graham Controls Consulting
Specializing in LonWorks technology
www.grahamcontrols.com
770.887.9024 (voice)
770.216.1668 (fax)
[email protected]
 
P

Peter Whalley

Hi Lynn,

Echelon have released a reference implementation of the LonTalk protocol stack as C source code which you can port to any processor you wish without having to start coding from scratch.

If you want to commercialise your product however you need to sign their Protocol Patent Licence Agreement which may or may not be acceptable to
yourselves.

See "http://www.echelon.com/products/Core/protocol/Default.htm";http://www.echelon.com/products/Core/protocol/Default.htm for more details.

Regards

Peter Whalley

Magenta Communications Pty Ltd

Melbourne, VIC, Australia

e-mail: peter*no-spam*@magentacomm.com.au
delete *no-spam* before sending
 
Michael Griffin:
> I will use a hypothetical case to illustrate the points.
...

> - Most PLC CPUs would be integrated into some form of MMI panel (likely a
> touch screen system). Many systems already use separate PLCs and MMI
> panels. If the I/O isn't directly connected to the CPU anymore, then
> there is no reason to put the CPU inside the control panel. This means
> the MMI panel and PLC markets would converge.

By the same token as the I/O not being directly connected to the CPU, neither need the MMI be. Indeed, since there's often (though not in the case you presented) several MMI panels, it's unclear at which of them it should be, anyway.

Once you untie the CPU from the I/O and MMI, it'll tend to migrate to whatever remaining tie is strongest. My guess would be clean power, but it could be anything (cooling, protection, network/external connections).

> - Special soft logic systems would be directed at particular markets.
> There would even be standard packages available for particular common
> applications.

Alternatively, the soft logic systems might converge, with special extensions aimed at particular markets.

> - With the PLC, I/O and most of the terminal blocks gone from the control
> panel, all that would be left in many cases is the disconnect and
> lock-out, power supplies, fusing, and the safety controller (which
> implements the safety interlocks).

Indeed, the safety aspect may be the greatest barrier to all this - as long as it needs to be interposed between the fieldbus and the actual device, integration of the bus into the device will remain half-hearted.

> What is needed to make the above work is mainly a standard, open,
> universal I/O network.

Indeed, a lot of things would work a lot better with a standard, open, universal I/O network.

> Traditional PLC manufacturers may not have the I/O market.

Well, if you can prise it out of their fingers... Why do you think the fieldbus standard turned out the way it did?


Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
C

Curt Wuollet

Hi Peter,

Thanks. I'll take a look even though I was discouraged by the Echelon site. I wish someone in the business would give me a better reason for using their scheme than so my networking dollars flow to them. Rather than debate the pros and cons with the advocates, I cut to the chase and explained what I need to do with the protocol to Echelon and asked them (publicly) if there is a way we could do it. So far, my attempts to open dialogs on opening protocols have been met with a rather impolite silence, except for Modicon who put me in touch with a lawyer who was polite but not very helpful. Hopefully, Echelon will at least have the courtesy to say no.(publicly) It's not that I am naive to the point where I expect them to contribute to the project or anything, it's just that so many people don't see where there is a problem. I am politely asking on behalf of a group that is operating in the public interest, for permission to further the use of these protocols. To make it possible for many more users to use these protocols. We have no commercial agenda and we favor no particular scheme. I firmly believe it would be a good thing to have an open platform that could bridge and provide a go between. It could only sell more IO and solve problems difficult to solve any other way. After all, you might think that they would actually _want_ people to use their protocols. But, unless there are direct dollars involved, the answer is not only no, but Hell no, and that is part of the problem.

Suppose you set out to replace Ethernet in the non-automation world, and all you offered was that your product also worked and it would make you and your "partners" lots of money. But, wait!, there's more. It would also restrict their choice and interoperate with nothing.

I don't think anybody would rush to invest in your company based on this value proposition. Your existing customer base might stay if they liked your other products enough. But if those were also "me too" products, even that would be doubtful. In fact, most of our gentle readers would regard the chances of success as highly improbable in that context. Yet these offerings are floated out with much fanfare in the automation market and then people wonder why the uptake doesn't meet projections. Since the direct dollars aren't exactly pouring in, I would think that someone will want to make the first move to differentiate their product by actually doing what it takes to make their product a cross platform Open standard and look towards the much greater indirect dollars that such a move should produce. If this seems like voodoo marketing, the vendors who have been less restrictive have clearly achieved greater market share. I won't mention them by name, but there are protos that practically everyone supports. Newer, more functional protocols should meet with even greater success if only the barriers can be removed. I think the first truly Open, reasonably functional, proto stands a good chance of becoming a standard and ubiquitous which is the whole object. It should be obvious by now that you can't have it both ways.

Regards

cww
 
F
Curt:

Don't expect Echelon to assist you in an open source project. There is no reasonable reason to expect them to. They are a publicly traded company and as such are in business to make a profit. They fully support the products they support, but obviously they are not going to spend valuable resources in helping you NOT USE their products. While they may not support you, that does not mean you cannot do it. Legally and technically, you CAN get a copy of the protocol and port it to any processor, you CAN develop your own transceiver, you CAN develop your own network management software, etc etc. Like any development this is not necessarily trivial. As a business, you have to make your own decision as to the financial viability of making versus buying.

I am constantly amazed at the number of people/companies that get ticked off because Echelon won't help them design their own system. You wouldn't call Microsoft and expect technical support in creating your own PC operating system would you? Technically you can create your own OS just don't expect MS to help you - the same with Echelon.

Your argument below about "locking" a customer in, doesn't ring completely true with LonWorks. If you choose to use LonWorks you are not locked into buying anything from Echelon (only exception is if you want a development tool). I can act as an integrator - buy finished hardware from third party companies (not necessarily Echelon), I can install them and configure them with third party tools (not necessarily Echelon). If I want to write my own code for those devices, I can purchase a third party graphical programming
tool. If I want to run the protocol on my own processor I can port the protocol or buy a port from a third party........ How much more open do you want?

To be fair, if your idea of open is to be able to modify the functionality of the protocol and how it works then no you can't do that. I personally don't think this is a bad thing. One benefit of having the protocol locked in stone is that every LonWorks device - from the ones created in 1992 until today can communicate to each other. I don't have to worry about your implementation vs another implementation.

With that restriction in mind, then you can go right ahead and port it to Linux or Mac OS-X or anyother OS you want. Have fun!

Fred
 
C

Curt Wuollet

In an effort to clear this up, I simply asked Echelon if we can do what we need to do. I'll post their answer, if any. If we can't, the point of how reletively open they are is moot. And most companies tend to avoid dependence on someones else's patents as that involves too much exposure to risk. That's why I think we need something
_really_ open to get many companies on board.

Regards
cww
 
M

Michael Griffin

On March 5, 2002 08:40 pm, Jiri Baum wrote:
<clip>
> By the same token as the I/O not being directly connected to the CPU,
> neither need the MMI be. Indeed, since there's often (though not in the
> case you presented) several MMI panels, it's unclear at which of them it
> should be, anyway.
>
> Once you untie the CPU from the I/O and MMI, it'll tend to migrate to
> whatever remaining tie is strongest. My guess would be clean power, but it
> could be anything (cooling, protection, network/external connections).
<clip>

Most machines probably have only one MMI panel. Even if there are several MMI displays, the actual MMI software could execute in the same box, (and probably on the same processor) as the PLC logic. The coupling of the control logic and display logic means the two need to work closely together. Extra screens and keyboard could be thin clients.

I don't see that "clearn power" would dictate location. Putting the PLC CPU a couple of meters closer to the power supply is no real advantage. I don't see your other factors making any difference either.

The significance that I see though, is that once local I/O has more or less disappeared in most applications, then users have no reason to buy their I/O from the same source as the PLC CPU except for the sake of I/O network compatability. If this compatability is no longer an issue, then a large piece of the system has gained the potential to be more "open".

> > - With the PLC, I/O and most of the terminal blocks gone from the control
> > panel, all that would be left in many cases is the disconnect and
> > lock-out, power supplies, fusing, and the safety controller (which
> > implements the safety interlocks).
>
> Indeed, the safety aspect may be the greatest barrier to all this - as long
> as it needs to be interposed between the fieldbus and the actual device,
> integration of the bus into the device will remain half-hearted.
<clip>

There is no technical problem here - this is already solved. After all, we are doing this today. This is nothing new. I am just pointing out what some of the *business* implications may be of carrying this trend (networked I/O) to a greater degree in the market.


> > Traditional PLC manufacturers may not have the I/O market.
>
> Well, if you can prise it out of their fingers... Why do you think the
> fieldbus standard turned out the way it did?
<clip>
If the PLC manufacturers aren't selling most of the I/O, then they won't control the market. If the I/O is built into the actuator, then the shoe may be on the other foot, and any potential PLC maker may have to conform to the protocol the actuator offers.

I suspect that it would not be easy to support a large number of different protocols with the type of integrated I/O I am talking about (integrated into the actuator). This would tend to cause the actuator companies to only support one (or a few) major protocols. The minor protocols wouldn't be economic.

Since no one company would control both ends of the system (or at least significant shares of both ends), there isn't the same potential to lock a customer in by offering a complete package. No one company would *have* a complete enough package to be able to ignore other companies.

You may possibly see another way for the market to develop. However, I think the above is at least a possible development. The significance of it is that it would force various companies who are selling complementary products to work together. I believe that it is in such situations that common standards can arise. This means that "open control" may arise due to factors unrelated to any explicit desire for it.


--

************************
Michael Griffin
London, Ont. Canada
************************
 
P

Peter Whalley

Hi Curt,

Since my previous posts I've had a closer look at the Echelon site. In essense it would appear Echelon hold patents covering some aspects of the LonTalk protocol. In order to use the protocol without infringing their patents you can either:

1. buy Neuron chips and use these.

2. write your own software and sign their Protocol Patent Licence Agreement

3. port their refernce implementation and sign their Protocol Patent Licence Agreement

The License Sgreement approach includes a number of provisions which would discourage some people including:

- agreeing not to make any negative comments about the protocol, the protocol specification Echelon products, Neuron chips etc etc.

- agreeing to provide Echelon with details of the number of products sold each month and allowing Echelon to audit your records

In addition you agree to pay Echelon $0.15 US per node ID number (like an Ethernet MAC address) that they assign to you plus an additional $0.15 US per node sold as an administration fee. The minimum number of ID numbers you can apply for is 16,384 so you would be up for $2,458 to start off. Also the ID number assigned to each product you sell must not be alterable by the user to whom you sell the product. This could be difficult (even impossible) to ensure if the protocol is distributed as source code.

I expect that this would all preclude the MAT/LinuxPLC project from writing their own LonTalk protocol stack. However if we use Neuron chips then these problems go away. I think we need to see the Neuron chip the same way we see an Ethernet driver chip and not try to re-invent this part of the wheel.

I think Echelon very much want to encourage the widest possible use of the LonTalk protocol but at the same time they:

- want to get a return on their substantial investiment in the development of the protocol

- want to protect the reputation of the protocol and

- want to protect the integrity of the protocol by preventing bad implementations from being put onto the market.

The issue of them providing node IDs is not really much different from the process of obtaining MAC addressess for Ethernet chips. They just want to make sure that every node in the whole world is uniquely addressable.

Regards

Peter Whalley
 
P

Peter Whalley

Hi Curt,

If _really_open is of primary importance then why not use SNMP. This is designed for monitoring and control and there are many existing implementations running under just about every operating system ever invented and many of these are distributed under GPL. It can also be very compact. The tar ball for CTM-1.3 ( "http://www.mcs-cityline.net/~lf/ctm/":http://www.mcs-cityline.net/~lf/ctm/ ) is only 30KB. My Google search on +snmp +gpl +linux turned up over 10,000 hits.

Next choice would be BACnet (ANSI/ASHRAE Standard 135-1995). Again its designed for control and monitoring purposes, runs on everything from RS232 and RS485 to LonTalk to Arcnet to Ethernet to any TCP/IP network. As far as I can see, the only cost is for the developer to purchase a copy of the standard when writing the code. The other nice thing is that the standard supports multiple levels of capability so it is possible to put a very small protocol stack on a smart sensor which only needs to support a small sub-set of the total standard but a HMI station can support the full standard providing a much broader range of capabilites. I have a copy of the standard if you need any specific information.

Regards

Peter Whalley
 
F
I'll be interested in seeing what answer you get. My gut feel is that the specific answer will depend a bit on what person within Echelon you asked. For example, if you ask your local Echelon sales rep, my bet is that you will get a negative answer because he is focused on selling you something, not directing you to develop your own. Good luck and let us all know what answer you get.

Regards,

Fred Graham
http://www.grahamcontrols.com
 
L
Thanks to Mr Whalley & Graham for pointing out that things at Echelon have changed. No doubt they have decided a 30% market piece of a growing
pie is better than a 99% market share of a shrinking pie! I forwarded the new info to our marketing folks who need to prioritize the dozens of protocol 'worlds' we have to work in. Nafem ( "www.nafem.org":http://www.nafem.org ) is the big hot protocol they are chasing me for today - a curious overloading of SNMP for real-time data and restaurant franchise management.

I for one don't expect and am not waiting for the proverbial "Single Open Standard" for the very reason that it's been tried a dozen times &
always fails. Does it fail due to the evil minions of dark vendors? Not really. They tend to fail on the fact that to do everything for everyone on every level requires a huge standard with large blocks of "optional" code - which means no real "standard" at all. Worse, once bugs and short-coming of this huge psuedo-standard are discovered, changes becomes a catch-22 - companies which have NOT done the standard yet
refuse to it until it's "fixed", while companies which have implemented the faulty standard demand the "fixes" wait a few years so they can breath & recoup part of their huge development costs. I spent 3 years of my life with "MAP/TOP" - the ultimate "Single Open Standard" and poster-child for all those truths.

In fact, the whole idea of it violates everything the "Web" and "Internet" have taught us. Did the FTP standard "get expanded" to include HTTP or Telnet or Modbus or MP3 music streaming so it could be the "Single Open Standard"? Of course not. The "Internet" is literally thousands of protocol standards working on a common TCP/UDP/IP base. The Industrial market will follow this model too or we're guilty of not learning from history.

I consider both Modbus and Ethernet/IP/ODVA "open enough" to be of huge benefit - the most important point of both is that publicly accessible spec & reference "C" code exists for each. Clicking an "I Agree" box for Schneider Electric which says I won't hold them liable if I screw up the world with bad Modbus designs doesn't bother me. Clicking an "I Agree" box for ODVA which says I promise to do a faithful, true-to-spec job of implementing Ethernet/IP & that I won't "absorb" the protocol into a proprietary protocol I call my own also doesn't bother me.

I hope LonWorks joins that list. I'm not so sure about clicking an "I Agree" box for Echelon which says we own someone money for each node sold and that we have to (at least indirectly) disclose to competitors what we're doing commercially is bit harder to like.

I also hope the FF/HSE people wise up & start offering free "reference code" before it's too late also!

best regards::

Lynn August Linse, Senior IA Application Engineer
15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618
[email protected] www.lantronix.com
Tel: (949)300-6337 Fax: (949)453-7152
 
Top