After Software, What's Next?

For the complete message this is responding to see http://www.control.com/thread/1327707041#1328379156

> Armin Steinhoff said:
>> Yes ... and the best answer I could find today is here:
>> http://www.mnbtech.com/index.php?id=164
>>
>> Software is the solution.

> Charlie Said: Your reference: http://www.mnbtech.com/index.php?id=164 describes "Mixed Technologies,"
> which is the addition of hardware solutions (FPGAs and Graphical Processing Units) to General Processing Units (common computer processing).

> So, hardware is at least some of the solution.

Programmable hardware is at least the solution.

> Charlie Said: There is a distinction between:
> Computation: the modification of input character strings (data) to produce displayable information, and
> Process Control: activities taken to ensure a process is predictable, stable, and
> consistently operates at the target level of performance with only normal variation.

From the view of computation there are no differences.

> Charlie Said: Computation can be used for process control, but it is not necessarily the best use for
> that technology. Appropriate uses of computation are cryptography, weather- and topological-map generation
> and updating, and art authentication, although we use it for most any task.

The use of mixed technology is the issue ... that means you can include the right hardware for your individual problem.

Best Regards
Armin Steinhoff
 
Charles, for many years process control was supplied by pure hardware solutions first using clever pneumatic computational elements, then by analog electronics. The industry migrated to digital circuitry in an effort to reduce cost, AND to gain functionality that was difficult, expensive, or impossible to do with hardware alone. In real process control systems, we do computations that are well beyond FPGA capability.

Yes, we can build hardware with great functionality, but software brings it to life. I don't know why you do not believe in software, but it is a retrograde attitude, and not productive. Software has enabled up to do control systems using elements such as model predictive control and dynamic matrix control that would be uneconomical if implemented in hardware alone, just to quote two examples.

The optimal control system can no longer be implemented without a very significant amount of software - although some suppliers insist on calling it "firmware." There is no "After Software," in my opinion. More likely - better software.

Dick Caro, CEO, CMC Associates
Certified Automation Professional (ISA)
Buy my books at the ISA Bookstore:
Wireless Networks for Industrial Automation
Automation Network Selection
Consumers Guide to Fieldbus Network Equipment for Process Control
 
C

Curt Wuollet

Or at least more of it.

cww

Dick Caro wrote:
> The optimal control system can no longer be implemented without a very significant amount of software - although some suppliers insist on calling it "firmware." There is no "After Software," in my opinion. More likely - better software. <
 
C

Charles Moeller

Vladimir:

CharlieM said:
>> My point is that there is a
>>more appropriate technology for process
>> control than computing--and it is
>>mostly hardware.

Vladimir wrote:
> What about a set of physical relays? :) History tells us relays can be used
> for process control... as hardware (physical relays) and as software (LD IEC 61131-3).

Yes, relays and switches are hardware. The first nuclear power plant (A1W) I qualified on as instructor-operator was originally fitted with a Hagan boiler-level control system (air relays). We later converted to an electrical system that used magnetic-amplifiers (mag-amps).

> So, I believe first-order question is the question about appropriate formal
> description... Question "hardware or software" is a second-order question.

That is correct. A parallel-concurrent language is a necessary next step toward parallel-concurrent operation. If we are limited to computer languages as a means of expression and computer hardware as a means of implementation, all of which are time-shared and shared-resource, we will forever be limited to linear-sequential operation. Despite the many computer languages and variations on computer hardware and architecture to date, we still do not have the basis of true parallel-concurrent operation.

But do not worry, help is close at hand. I have made solving this question my life’s work.

> BTW, I think PC can not be described in terms of Turing Machine because of the timers at least.

Time and timers can be converted to numbers in space, which is what we do all the time using TMs, sundials, our wall clocks, etc.

Best regards,
CharlieM
 
V

Vladimir E. Zyubin

CharlieM > The human psychology and physiology is able to handle situational dynamics in a parallel-concurrent manner.
...

Can you prove your words by a link? I am sorry, my investigation on the topic (Miller's law, short-term and long-term memory, software psychology, etc.) leads me to a different conclusion. BTW, I have fixed it in an article about information complexity.

> Such controller activities performed on a time-shared basis is what we have now
> with TMs. What is needed is the parallel-concurrent alternative.

In my opinion, "parallel-concurrent" means just independent... if you independently describe a thread (independently from others threads) you can produce more simple, reliable, readable, maintainable code. In control software parallelism of the physical processes allows programmers to simplify the description. It is absolutely different to other fields of computing (e.g. supercomputer programming) where programmers crack their brains to get a code that will utilize all power of the platform. And the code can be very complex, importable, etc.
 
C

Charles Moeller

James:

>> CharlieM: "Simpler is better."

> I think we'd all agree with that... up to a point. It can be difficult to
> define "simpler." For example, imagine a large machine (packaging, web press,
> doesn't matter) with a mechanical drive train. It some ways this is very simple.

---- snip ----
<b>Moderator's note:</b> See thread http://www.control.com/thread/1327707041#1328381434 for complete post


> CharlieM: "The applications I am thinking of are the toasters, home
> security, vehicle subsystems, factory automation, etc."

> Ah, now I see the problem. We've been talking at cross-purposes because you
> equate factory automation with toasters. I suppose there are a handful of tasks
> that are as simpler as toasters; a simple zero-pressure chain driven live
> roller accumulation conveyor, for >example.

---- snip ----

Your points above are valid and well-made. But complicated high-end factory machines and manufacturing processes originated in simpler times and means. Also, for every 100-yard long, 120-shaft paper-making machine, there exist hundreds of much simpler machines and potential automation projects. Linear-sequential software was complex at the outset and has grown at least in proportion to the machines it serves at that upper end. Perhaps the Peter Principle now applies.

Somewhere along the way to modern times, technology skipped over a nice alternative to linear-sequential data-processing: that of real time parallel-concurrent operation.

What I’m proposing is a parallel-concurrent method of process specification that can be implemented in parallel-concurrent hardware now on the simpler applications such as toasters, low-end assembly and fabrication machines, automotive braking systems, etc. As time goes on, this simpler, safer, and less complex method will grow up to encompass all the tools and processes of the day.

Best regards,
CharlieM
 
C

Charles Moeller

Armin:
---- snip ----

> The use of mixed technology is the issue ... that means you can include the
> right hardware for your individual problem.

The right hardware can do the tasks required in a parallel-concurrent mode, but if you insist upon run-time software as we know it then you are necessarily going to have linear-sequential operation as a result.

Best regards,
CharlieM
 
> [ clip]
> That is correct. A parallel-concurrent language is a necessary next step toward parallel-concurrent operation. If we are limited to computer languages as a means of expression and computer hardware as a means of implementation, all of which are time-shared and shared-resource, we will forever be limited to linear-sequential operation. Despite the many computer languages and variations on computer hardware and architecture to date, we still do not have the basis of true parallel-concurrent operation. <

Parallel-concurrent operation happens today on every standard PC. Every PC has a lot of peripheral controllers (e.g. the GPUs) which are working physically parallel and independent from the CPU. The old SMP systems and also the cores of multicore CPUs are working complete parallel.

If you add FPGA based PCI devices as peripheral devices it adds a lot of parallel operations to the PC.

Is this not a base for physical parallel-concurrent processing ?

Best Regards
Armin Steinhoff
 
> Armin wrote:
>> The use of mixed technology is the issue ... that means you can include the
>> right hardware for your individual problem.

CharlieM wrote:
> The right hardware can do the tasks required in a parallel-concurrent mode,
> but if you insist upon run-time software as we know it then you are necessarily going to have linear-sequential operation as a result.

Sorry that's not the case if the computing hardware nodes (w/o a CPU) are programmable FPGAs e.g.

Best Regards
Armin Steinhoff
 
V

Vladimir E. Zyubin

> CharlieM said:
> A parallel-concurrent language is a necessary next step toward
> parallel-concurrent operation.

AFAIK, there are a lot of such languages from occam and Esterel to VHDL. LD, FBD, SFC (IEC 61131-3) have parallelism at some extent and level as well.

> Despite the many computer languages and variations on computer hardware and architecture to
> date, we still do not have the basis of true parallel-concurrent operation.

But why must we have basis of _true_ parallel-concurrent operation? I personally see no problem with "seemed like true" parallel-concurrent operation. More over there are well known problems with physical parallelism that can produce so called races. http://en.wikipedia.org/wiki/Race_condition

> But do not worry, help is close at hand. I have made solving this question
> my life’s work.

It will be very interesting to read about.

>> Vladimir said:
>> BTW, I think PC can not be described in terms of Turing Machine because of the timers at least.

> CharlieM said:
> Time and timers can be converted to numbers in space, which is what we do
> all the time using TMs, sundials, our wall clocks, etc.

Mostly agreed. But question "What is time" is very complex to speak about. I prefer to speak in terms of time intervals or events: timers, sundials, clocks, etc. produce events that can be counted up. Yes, it can be presented as a number, but TM "as is" does not include such kind of numbers and does not assume any uncontrolled changes on its tape. Because it makes impossible to define the computational complexity of algorithm. The main question in theory of computation. TM is intended for calculations, but neither for a communication with an external environment nor with other TMs, nor thinking in terms of time intervals... delays, timeouts, latencies. And so on.

So, the question about TM is not simple. It looks like the model is not fit to think about control algorithms (about concurrency and time intervals).
 
C

Charles Moeller

Vladimir:
> CharlieM wrote: The human psychology and physiology is able to handle situational
>> dynamics in a parallel-concurrent manner.
...
Vladimir wrote:
> Can you prove your words by a link?

You can experience proof for yourself by observing and thinking.

> I am sorry, my investigation on the topic (Miller's law, short-term and long-term
> memory, software psychology, etc.) leads me to a different conclusion. BTW, I
> have fixed it in an article about information complexity.
>
>> CharlieM wrote: Such controller activities performed on a time-shared basis is what we have now
>> with TMs. What is needed is the parallel-concurrent alternative.

Vladimir wrote:
> In my opinion, "parallel-concurrent" means just independent... if you
> independently describe a thread (independently from others threads) you
> can produce more simple, reliable, readable, maintainable code. In control
> software parallelism of the physical processes allows programmers to simplify
> the description. It is absolutely different to other fields of computing
> (e.g. supercomputer programming) where programmers crack their brains to get a
> code that will utilize all power of the platform. And the code can be very complex, importable, etc.

Simple control science is the specific area of my focus. Parallel-concurrent indeed means “mostly” independent, as there could be some parts of some activities that are dependent upon others. The operation of threads via computer, in serial, parallel, or time-shared fashion however, is different from doing any or all of the activities “while” they are all active in configuration-bound hardware. For example, a certain 16-bit adder may be clocked up to 40 MHz, but uses less power and results are available more rapidly if operated in a <b>flow-through</b> manner, performing operations <b>as</b> the operands are presented. Efficiency and speed are gained by local control in hardware over centralized control via software.

Best regards,
CharlieM
 
Mr. Moeller: Are you advocating some new hardware architecture? It would help this discussion if you would reveal your thoughts.

Many years ago, my colleagues at The Foxboro Company were making many of the same points I see in your discussions. We were exploring the use of Concurrent Pascal (http://en.wikipedia.org/wiki/Concurrent_Pascal) for programming real-time process control systems. I have found that this language was useful for operating systems and real-time systems software, but that SFC (Sequential Function Charts) were more useful in describing the serial/parallel flow of real-time process control applications. As you know, the multitasking capability of real-time operating systems used in PLCs and process control systems easily handle the execution of programs written within the SFC/Grafcet structure.

Dick Caro
 
C

Charles Moeller

> Yes, it can be presented as a number, but TM "as is" does not
> include such kind of numbers and does not assume any uncontrolled changes on
> its tape. Because it makes impossible to define the computational complexity of
> algorithm. The main question in theory of computation. TM is intended for
> calculations, but neither for a communication with an external environment
> nor with other TMs, nor thinking in terms of time intervals... delays, timeouts, latencies. And so on.

> So, the question about TM is not simple. It looks like the model is not
> fit to think about control algorithms (about concurrency and time intervals).

Vladimir:

You have stated the problem! That is my point. It is precisely why I am investigating alternative methods of control. The TM, as a paradigm, falls short of being able to describe various evident aspects of time. The TM can only deal with linear-sequential frames containing static data. If we go to the logic upon which the computer is based, we can find that the only temporal notion it can accommodate is the concept of coincidence. If we go back to the ancient philosophers’ logic, we find the same limitation on static time. Closer to modern times, the French philosopher Henri Bergson noted this limitation in his 1889 essay <i>Time and Free Will</i>, in which he asked of logic, "Where is the becoming?" More recently, Physicist Dr. Lee Smolin in <i>The trouble with Physics</i> asked in 2006, "How can we represent time without turning it into space?"

My work on this subject expands the foundations of logic (words of description and operators), the corresponding logic elements (hardware), and the application of these to simple process control situations.

Best regards,
CharlieM
 
C

Charles Moeller

Armin:

---- snip ----
> Parallel-concurrent operation happens today on every standard PC.
---- snip ----

> If you add FPGA based PCI devices as peripheral devices it adds a lot of
> parallel operations to the PC.

> Is this not a base for physical parallel-concurrent processing ?

"Processing," as a very common term in use today, means linear-sequential operation under the timing of software on a Turing-type machine.

So, at best you may get linear-sequential-based parallel-concurrent processing.

Best regards,
CharlieM
 
W

William Sturm

CharlieM wrote: <<Efficiency and speed are gained by local control in hardware
over centralized control via software>>

While that may be true, I believe the software to make all of those parts work together as an integrated system could get very complicated. I would like to think that there is a simple way, but I cannot imagine it at this time.

An example of concurrent hardware is a microcontroller with integrated peripherals. The TI MSP430 can go into a low power sleep mode and it's A/D, Counters... can continue to do their job and awaken the CPU when needed. It is a very neat chip, actually.

Bill Sturm
 
Armin Steinhoff wrote:
>> Parallel-concurrent operation happens today on every standard PC.
>> ---- snip ----

>> If you add FPGA based PCI devices as peripheral devices it adds a lot of
>> parallel operations to the PC. Is this not a base for physical parallel-concurrent processing ?

Charles Moeller wrote:
> "Processing," as a very common term in use today, means linear-sequential operation under the timing
> of software on a Turing-type machine.

> So, at best you may get linear-sequential-based parallel-concurrent processing.

So you want something like a clockless analog data flow computer?

Best Regards
Armin Steinhoff
 
What is the problem you guys are trying to solve? Yeah, modern programming still dates back to Turing machines, so what? A battery powered ARM processor that runs your tablet is 10 times more powerful than you need for the majority of control tasks, even a majority of motion control tasks (which are becoming more and more distributed anyway).

I feel that this discussion is largely academic and doesn't really service the needs of the group, who are more interested in real problems such as the fact that the big PLC companies are slow to release anything innovative even in terms of Computer Science of 30 years ago. Or how about getting a real shared tag database between motion, HMI, and PLC without going to a bloated database/OPC monster? Or how about getting Vendor A to talk to Vendor B because you have to support machines built 25-30 years ago? Those are real problems, not whether the underlying mechanism runs on hardware, software, firmware, or Jello-ware.

KEJR
 
V

Vladimir E. Zyubin

> CharlieM wrote: More recently, Physicist Dr. Lee Smolin in <i>The
> trouble with Physics</i> asked in 2006, "How can we represent time without
> turning it into space?"

I can not be kept from the question:
What about "How can we represent space without turning it into time?" :)

Lee Smolin is right when he try to point out a problem, but his question is not correct enough.
The situation with time and space is symmetric:
time -- space
changes -- objects
duration -- length

> My work on this subject expands the foundations of logic (words of description and operators), the
> corresponding logic elements (hardware), and the application of these to simple process control situations.

May it be told now? It would be interesting to look at. And it is very pleasant to communicate with the person with such broad knowledge in philosophy. And I suspect, the annotation, that sounds so intriguingly, may has really interesting basis.
 
C

Charles Moeller

> Mr. Moeller: Are you advocating some new hardware architecture? It would help
> this discussion if you would reveal your thoughts.

Mr. Caro: I have been revealing my thoughts over the past week as this discussion has proceeded. The present computer architecture is well suited for linear-sequential instruction-bound control. It supports independent threads only on a time-shared basis (unless you have a processor per thread).

What I have been writing about is a way to configure hardware such that it naturally and automatically performs in a parallel-concurrent manner <b>as needed</b>, instead of periodically under software control. Such arrangements would be classed as <b>non-computational</b> means of control. The architecture would not be fixed, but would be modifiable so as to especially suit each type of application. This new path taken because it seems the Turing-type paradigm has just about run its course.

I do not claim that what we have in computation is not useful, because it is, but there are currently diminishing returns for the increasing trouble of smaller, denser, faster hardware and voluminous software. In order to move on, we (at least some of us) should change direction. This is especially true for the smaller and less demanding control tasks, in which only a few simple functions are required and there is a small number of I/Os. Also in this category are simple control tasks that have safety-, time-, and mission-critical requirements and are not well-served by the expensive GHz behemoth chips.

Best regards,
CharlieM
 
C

Charles Moeller

Bill:

CharlieM wrote:

>> Efficiency and speed are gained by local control in hardware
over centralized control via software

Bill Sturm wrote:
> While that may be true, I believe the software to make all of those parts work
> together as an integrated system could get very complicated. I would like to
> think that there is a simple way, but I cannot imagine it at this time.

The arrangement of which I wrote (specifically, the 16-bit adder) used no software and no clock. It could have been clocked up to 40MHz, but it had a flow-thru option which didn’t require a clock. When using this clock-less option, the two 16-bit operands were simply presented at the input ports and after about 20 nsec. the sum was stable and available at the output port.

> An example of concurrent hardware is a microcontroller with integrated
> peripherals. The TI MSP430 can go into a low power sleep mode and it's A/D,
> Counters... can continue to do their job and awaken the CPU when needed. It is a
> very neat chip, actually.

Yes, a great chip! Part of it can operate independent of the TM! Now that is the part I like most!

Best regards,
Charlie
 
Top