Open control systems ???

  • Thread starter Peter Wurmsdobler
  • Start date

Thread Starter

Peter Wurmsdobler

Open control systems can be understood as multi-vendor control systems, composed of components that comply to open, non-proprietary standards, for hardware as well as for software. This is a general definition, but there might be other views of open control, other perceptions of the words and terms 'open' or "open control". As Open Control Laboratory director, I would be interested
to learn what "open control" means to you, whether you are a system integrator, an end-user, or a supplier of control components. What does "open control" mean to you in terms of components in a control system (HMIs, PLC, DCS), in terms of their architecture and the their granularity (very important!), in terms of
protocols between those components, etc. ?

I would beg to differ from this very popular definition.

We are looking at multivendor support when we say an open control system.
But this is only the hardware standpoint.
We should be able to replace the monitor of the system with any monitor available in the world.
We should be able to replace a subsystem of the system with another subsystem and so on.

Please take the next line as a question from the instrumentation community to everybody in the list;

But on the hand are we also looking at having vendor and manpower independence for replacement of knowledge based items and software components?

IMHO, the entire point of open control, and the mechanism through which it delivers benefit to the user, is in the "unbundling" of system components (including software components) from one another AND from support services. This allows the selection of best-in-class for each category of product AND service. It's all about removing unnecessary limits, whether the limits are hardware-based, software-based, or human-based.

This requires a combination of extensive use of open interfaces and also the adoption of policies which separate support costs from purchase costs. The industry is (ever so slowly) plodding in this direction. Of course, the vendors will tell you it's all the users' fault <grin>.

Ken Crater, Inc.
[email protected]

James R. Fall


As one of the few vendors that has taken the approach you define, I applaud your definition of an open control is the "unbundling" of the entire system. Early in MDSI's business we unbundled the software from any hardware. The next step was the access data be defined by the used. The Third step we unbundled the integration services from the product. In the fourth step was publishing an API to enable companies to develop their own technology on top of ours (our API is continuing to get broader and deeper). The fifth step is to create components that can be substituted.

And, a key aspect in all of this is how broadly one defines the control. Most vendors try to narrowly focus the control as being the HMI or the PLC or the motion or servo so that they can claim to be open. The control needs to be a single platform for doing all of the above that is reconfigurable for the application. Not separate applications that do not unbundle all aspects. For example a motion control card does not unable their servo algorithms.

So, I agree with you that unblundling is the key. The second is ease of reconfiguration of those components for the application.



James R. Fall E-mail: [email protected]
President and CEO Voice: (734) 327-8200
Manufacturing Data Systems, Inc. FAX: (734) 769-7508
220 East Huron Street, Suite 600
Ann Arbor, MI 48104-1912

Curt Wuollet

Sounds good to me. The platform I'm working on will run any software. That way if people are using your software and the implicit knowlege and experience therein, it's because it solves their problems, not because it's the only thing available on your hardware. I don't think there can be Open without an unbundling of hardware and software and at least the possibility of switching one or the other. Of course, I'm a radical I guess. I think people should be using your stuff because it's good, not because it's their only choice. It's that competition thing.



Peter Wurmsdobler

> an open control is the "unbundling" of the entire system. <

Even though it might sound academic, I would like to add some thoughts, because "unbundling" is not all. First, what is a system:

1. A system is defined by its boundaries to its environment

2. An interface will define the interaction of the system with its environment.

3. A system is composed of systems, components which are systems themselves
with other interfaces.

However, if and only if these interfaces

( ( are vendor independent ) AND
( are not owned by some entity ) AND
( (are a result of consensus ) OR
(reflect proprietary practice and technology with
control released by initiator) ) )

"unbundling" can happen with multi-vendor support, even on different levels. Separating HW from SW adds one internal interface into a controller, e.g. ISA/PCI busses and the instruction set of a general puropose CPU. Separating the OS to application SW will add another one, POSIX could be such an interface
( note that MS Win32 API is not an open interface in the sense above). Separating the programming environment from the runtime system could be another step. What ever granularity is chosen, only introducing "open interfaces" in a system in the above sense can make unbundling possible as it allows more parties to play in the game.

Curt Wuollet

Hi Peter, Jim, all

One of the problems with unbundling HW and SW is that in many cases it simply can't be done at a useful level. If you peel the software off a typical PLC. you have a fairly specialized piece of hardware. Nothing else is gonna run on that particular machine as the software is written very close to the hardware. It's the software that generalizes the combination by supporting a variety of familiar functions. This is because current automation technology (mostly) follows a deeply embedded model. This wrings the most out of a processor chosen for cost at the expense of requiring pretty specialized skills and high upfront costs. This is exacerbated by the fact that each company does their own. This model is excellent for high volume consumer goods that sell in the millions and we see examples every day. Microwave ovens, personal electronics, toys, yada yada. Some come at amazing price points because of the sheer volume. Some few automation products actually achieve the volumes for this to have been a great choice. The others are why we pay a lot for automation gear.

At the other end we have the ultimate unbundled machine, the PC. That is, if you can buy one or assemble one that doesn't include the Microsoft tax on all pc's. Even if you pay for the obligatory copy of Windows and throw it away, you are left with an absolute wonder of what volume can do. If you carefully avoid Winjunk like half-modems and half-soundcards and the like, you have an extremely low cost machine that can run software completely of your choosing. While most people abdicate this choice by allowing themselves to be sold a bundle and using it without a second thought, the true, low penalty, best of breed, concept of unbundling is possible on this machine for at least a few more years. There is very little automation software that really makes use of this freedom. most choosing instead to wedge themselves into the bundling scheme. And the number of automation tasks that the PC is capable of is severely limited, almost decimated. as a result. The PC with proper software is vast overkill for almost any automation task but the commodity cost makes it practical. The PC has a few problems in this arena, even with proper software. The IO available at commodity pricestends to be TTL levels and require external convertors, relays, etc. And because the PC has relatively few slots, it tends to come in large increments. This limits the flexibility quite a bit verses the small increments available in PLCs. And very little commodity hardware works like PLC IO. Networked IO helps a lot to overcome this difficulty but is not commodity priced at present and anything but standardized. PC's can be hardened and the difficulties overcome but cost advances rapidly.

So we have the predominant platform which is quite specialized and not well suited to unbundling and a great commodity platform which is well suited to unbundling but lacks the specialization to be well suited for the factory floor. And very little really suitable software exixts. For these purposes I would include products like SoftPLC tm. and the few that use some sort of run time executive and RTOS products. And of course, AutometionX and MAT/LPLC when it's ready. Most of these are frightfully expensive comparedto commodity prices and even medium to large PLC systems.

In order for true unbundling to take place and openness to be really practicable, we need a PLC type platform that supports a wide variety of software. Uses the good points of both platforms. Sort of a PCPLC. One platform that can be used with enough different software and in enough different situations to achieve commodity volumes and the Holy Grail of standardization. One platform that could cover the great majority of PLC applications well. It has to be vendor blind to be widely supported like PC's are. Open Hardware.

And we need software that is open or at least interchangeable on that platform. The products I listed above for a start and if the existing PLC vendors were to climb aboard, we would have many good choices.

And that is the thinking behind my latest Open Hardware project and the MAT/LPLC project.

I am really interested in discussing this point of view. What's right about it, what's wrong about it, and how it could be done better. It sure sounds like a workable concept to me. Or at least a good first pass at a solution. Try to imagine it.