After Software, What's Next?

C

Charles Moeller

Vladimir:

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?"

---- snip ----

Vladimir E. Zyubin wrote:
> 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

Time and space are not exchangeable, despite Minkowski and Einstein. The time domain is a special circumstance, as one can go perceptively forth and back in space, but not in time. The dimension of time in common usage is also (as well as space) defined as smooth, infinitely dense, and infinitely extensible. In the constructed universe mediated by numbers and arithmetic, the properties of time are generally taken to be the same as, and in fact are mapped onto, a fourth spatial dimension having the general character of extension, or length. We use a counting mechanism to translate time-ticks into the space domain, as can be seen on the faces of our clocks. This practice fits nicely into our arithmetic computers, but it adulterates and obscures the true character of the time domain. <i>Temporal logic</i> in computers relies heavily on numbers and fixed conditions and—wonder of wonders—takes place wholly in the space-domain.

Best regards,
CharlieM
 
C

Charles Moeller

> Charles, for many years process control was supplied by pure hardware solutions

---- snip ----

> 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:

All control problems do not require a computer, but that’s what is being used in most cases, simply because there is no easier or well-documented alternative. Sometimes a microprocessor is overkill or not appropriate. But in the cases when you absolutely need computing, then you necessarily must have software. I agree that computation has allowed us to get to our present technical position, but it is only one means of solving control problems. There are other means, one of which I have been addressing.

Software provides direction to the hardware, but hardware actually performs all the functions. Software can only tell the hardware <i>what it is time to do</i>. Now if there was a way to build into the hardware a sense of time so that it would automatically do what it is time to do, we would need less software, or in some cases, none. That would be safer, ease the class of faults attributable to software, and cost less to build and maintain.

We have had decades of better software and we still get reports like The Standish Chaos Report [a] that shows a (currently) backward trend in software projects' success rates:
<b>32% Successful</b> (On Time, On Budget, Fully Functional)
<b>44% Challenged</b> (Late, Over Budget, and/or Less than Promised Functionality)
<b>24% Failed</b> (Canceled or never used)
a. http://www.galorath.com/wp/2009-standish-chaos-report-software-going-downhill.php

Other reports and articles indicate software production efficiency is only about 50% for the successful 32% of projects. That is because as much time is spent on correcting software as is spent on its creation. Production efficiency is even less for the “challenged.” The "failed" category gets a zero, of course.

My aim is to improve control engineering and the control engineer’s lot.

Best regards,
CharlieM
 
C

Curt Wuollet

That argument ignores the reality of economics.

A different piece of hardware for each application is not feasible in comparison to a piece of hardware that can do almost anything and software to tailor it to the task. There are a lot more people who can do the software than those who could do the hardware. And it takes serious investment and capital to make the hardware, much more than it takes to make the software. In fact, the toolchain I use is free and runs on top of a Free os. It is more economic to use commodity generic hardware and program it for even trivial tasks. It may not be to your liking or even mine, and may not be esoterically correct, but the customer simply doesn't care and they pay me. I suspect that will prevail for quite some time unless they come up with a practical silicon compiler and foundry at very low cost.

Regards
cww
 
V

Vladimir E. Zyubin

CharlieM wrote:
>>> More recently, Physicist Dr. Lee Smolin asked, "How can we represent time without turning it into space?"

Vladimir E. Zyubin wrote:
>> The situation with time and space is symmetric.

CharlieM wrote:
>Time and space are not exchangeable, despite Minkowski and Einstein.

…and despite Lee Smolin.

I must confess, most physicists do not understand both time and space. Lee Smolin, according his question, just one of them. IMHO. With the best of my regards to Minkowski, Einstein, Lee Smolin and others.

CharlieM wrote:
> The time domain is a special circumstance, as one can go perceptively forth and back in
> space, but not in time.

The "Space" concept is not simplier than time.
Space can be non-euclidean, for example.

> The dimension of time in common usage is also (as well as space) defined as smooth, infinitely
> dense, and infinitely extensible. In the constructed universe mediated by numbers
> and arithmetic, the properties of time are generally taken to be the same as,
> and in fact are mapped onto, a fourth spatial dimension having the general
> character of extension, or length. We use a counting mechanism to translate
> time-ticks into the space domain, as can be seen on the faces of our clocks.

As to me, clocks are just changing objects, time and space just forms of its existence. Clocks have no sense without changes... or events. And what we have is called just "metrological routines"... that need both space and time :)

Ok. :-x

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 flow-through manner, performing operations as the operands are presented. Efficiency and speed are gained by local control in hardware over centralized control via software.

It sounds like low-level implementation question, that can save a couple of Watts. Kinda changeable frequency of the quartzes. I can imagine which way that excellent idea can be used in embedded systems, but I can not see much sense to use it for objects that demand tens and hundreds of kiloWatts.

Best regards, Vladimir E. Zyubin
 
Dick Caro wrote:
>> Mr. Moeller: Are you advocating some new hardware architecture? It would help
>> this discussion if you would reveal your thoughts.

Charles Moeller wrote:
> 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).

A multicore CPU with 8 cores supports 8 independent threads. If multi-threading is supported for each core we have additionally at least 8 impendent threads running.

GPUs are supporting hundreds of cores ...

Charles Moeller wrote:
> What I have been writing about is a way to configure hardware such that it naturally
> and automatically performs in a parallel-concurrent manner as needed, instead of
> periodically under software control.

When you use a SBC with an Atom processor which includes a big FPGA on the same chip ... you could use linear-sequential and true configurable parallel execution.

Charles Moeller wrote:
> Such arrangements would be classed as non-computational 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.

It's already done by processing boards with multible FPGAs ... or a network of FPGA based processing node.

Best Regards
Armin Steinhoff
 
J

James Ingraham

cww: "And it takes serious investment and capital to make the hardware, much more than it takes to make the software... unless they come up with a practical silicon compiler and foundry at very low cost."

I agree completely... well, almost completely. We're well on our way to low cost / free hardware design tools (e.g. SystemC). And I've been hearing about circuits printed by ink-jet for at least a decade. So it may indeed be possible one day to create hardware with no more difficulty or expense than current software development.

Of course, it won't be any more reliable than current software, either. If you write software the traditional way and "compile" it to hardware you'll still have the exact same propensity for bugs. And somehow I doubt that ink-jet printed circuits are going to be up to the standards that the big automation companies have for making hardware robust and reliable.

-James Ingraham
Sage Automation, Inc.
 
Dick Caro wrote:
>> Charles, for many years process control was supplied by pure hardware solutions
> ---- snip ----
>
>> 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.

Charles Moeller wrote:
> All control problems do not require a computer, but that’s what is being used in most
> cases, simply because there is no easier or well-documented alternative. Sometimes a
> microprocessor is overkill or not appropriate. But in the cases when you absolutely
> need computing, then you necessarily must have software. I agree that computation has
> allowed us to get to our present technical position, but it is only one means of solving
> control problems. There are other means, one of which I have been addressing.

> Software provides direction to the hardware,

Software can do nothing because it is just a special configuration of a piece of passive hardware ... we call it memory.
I have never seen a passive memory providing direction to the hardware in common. And that is OK so :)

> but hardware actually performs all the functions. Software can only tell the hardware
> what it is time to do.

Again software does nothing .. it must be executed.

> Now if there was a way to build into the hardware a sense of time so that it would
> automatically do what it is time to do,

We have it since more then 50 years ... we call it timer hardware which can create timer events. These timer events are processed by the execution of OS tasks or the execution of an application program.

> we would need less software, or in some cases, none.

You need in all cases well configured and working hardware that fits to the application.
How would you handle hardware errors if all is processed in hardware

> That would be safer, ease the class of faults attributable to software, and cost less to
> build and maintain.

> We have had decades of better software and we still get reports like The Standish
> Chaos Report [a] that shows a (currently) backward trend in software projects' success rates:
> 32% Successful (On Time, On Budget, Fully Functional)
> 44% Challenged (Late, Over Budget, and/or Less than Promised Functionality)
> 24% Failed (Canceled or never used)
> a. http://www.galorath.com/wp/2009-standish-chaos-report-software-going-downhill.php

And what about statistics about hardware projects ?

I have seen a lot of hardware products with a lot of bugs. That hardware bugs could only be fixed by software because the bug fixes at hardware level was to expensive and needed too much time.

> Other reports and articles indicate software production efficiency is only about 50% for
> the successful 32% of projects. That is because as much time is spent on correcting
> software as is spent on its creation.

OK and how much time and money is needed to fix hardware bugs?

Best Regards
Armin Steinhoff
 
Mr.: Moeller:

You said
> What I have been writing about is a way to configure hardware
> such that it naturally and automatically performs in a parallel-concurrent
> manner as needed, instead of periodically under software control. Such
> arrangements would be classed as non-computational 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.

Have you applied for a patent on this new hardware class? I would enjoy hearing more about it once you have protected your invention.

Dick Caro
 
C

Charles Moeller

<b> Moderator's note:</b> This message originally quoted the entire message in post http://www.control.com/thread/1327707041#1328688315. Rather than reproduce it here, please refer to it.

---- snip ----

Charles Moeller wrote:
>> 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.

Armin Steinhoff wrote:
> It's already done by processing boards with multible FPGAs ... or a network of FPGA based processing node.

Armin:

At great cost. Suppose there was a better hardware language that incorporated time such that the hardware would know when to perform its functions without software. Suppose this temporal logic hardware could be implemented in a small portion of a small FPGA. The combination could be applied to low-level applications like toasters, fuel injection systems, braking systems, and simple assembly and fabricating machine automation for pennies. In the case of plant automation, the plant electrician or engineering technician could configure the chips. Third-world countries could automate factories without being dependent upon computer software and hardware experts.

Best regards,
CharlieM
 
C

Charles Moeller

Mr. Caro:

> Have you applied for a patent on this new hardware class? I would enjoy
> hearing more about it once you have protected your invention.

Working on it. Looking for support.

Best regards,
CharlieM
 
C

Charles Moeller

CWW:

> That argument ignores the reality of economics.

> A different piece of hardware for each application is not feasible in
> comparison to a piece of hardware thatcan do almost anything and software to

---- snip ----

Low-cost configurable hardware in the form of FPGAs would be more appropriate for the low-level applications.

Best regards,
CharlieM
 
C

Charles Moeller

<b>Moderator's note:</b> This message originally quoted the entire message in post http://www.control.com/thread/1327707041#1328718709. Rather than reproduce it here, please refer to it.

James:

We can open up the world of low-level applications to automation if we eliminate the requirement and ills of software. The hardware has to be there anyway.

Best regards,
CharlieM
 
[ clip]
> Armin Steinhoff wrote:
>> It's already done by processing boards with multible FPGAs ... or a network of FPGA based processing node.

Charles Moeller wrote:
> At great cost.

That's not the case. It is possible to buy a FPGA board with a e.g. Spartan 6 FPGA for less than $100.

> Suppose there was a better hardware language

Sorry what is a hardware language? I know only hardware description languages like VHDL e.g.

> that incorporated time such that the hardware would know when to
> perform its functions without software.

The operation of a FPGA is based on software ... it's called firmware and is located mostly in serial EPROMS.
But the firmware will not be executed by a MCU. However ... nothing works without software :)

> Suppose this temporal logic hardware could be implemented in a
> small portion of a small FPGA. The combination could be applied to
> low-level applications like toasters, fuel injection systems,
> braking systems, and simple assembly and fabricating machine automation for pennies.

Pennies? Hardware and ist replications cost much more.

> In the case of plant automation, the plant electrician or
> engineering technician could configure the chips. Third-world
> countries could automate factories without being dependent upon computer software and hardware experts.

That's exactly what this company is already doing ...http://www.mnbtech.com

Best Regards
Armin Steinhoff
 
C
That's possible, they have been replacing scatter logic for years, but usually only in volume applications.

I'm not sure what magic would change that.

Regards
cww

> Low-cost configurable hardware in the form of FPGAs would be more
> appropriate for the low-level applications.
 
C

Charles Moeller

CWW:

I take it the "scatter logic" to which you refer is what we used to call "random logic."

Curt Wuollet wrote:
> That's possible, they have been replacing scatter logic for years, but usually only in volume applications.

>I'm not sure what magic would change that.

Looking for the magic.

CharlieM wrote:
>> Low-cost configurable hardware in the form of FPGAs would be more
>> appropriate for the low-level applications.

Best regards,
CharlieM
 
C

Charles Moeller

James:

> We're well on our way to low cost / free hardware design tools
> (e.g. SystemC). And I've been hearing about circuits printed by ink-jet for at
> least a decade. So it may indeed be possible one day to create hardware with
> no more difficulty or expense than current software development.

> Of course, it won't be any more reliable than current software, either.
> If you write software the traditional way and "compile" it to hardware you'll
> still have the exact same propensity for bugs. And somehow I doubt that ink-jet
> printed circuits are going to be up to the standards that the big automation
> companies have for making hardware robust and reliable.

The biggest problem designers have with control software is the requirement to repetitively translate to and from the space domain.

Logic, software, and computational prowess are concentrated almost wholly in the space-domain. There is no temporal logic that is native to the time-domain. Data is taken from the space- and time-domains (or space-time domain) of the real world via sampling and selection and filed in memory (space-domain). A list of instructions (space-domain) is applied to the data and it is processed by means of Boolean logic operators (all space-domain transformations that can be laid out in row- and column-truth-tables). All reference values, if any, are discrete.

One of the major difficulties faced by software designers is although they live and work in three-dimensional space and multi-threaded time, they are constrained to create systems that reside completely within the space-domains of computers. These systems must sense and react to real world temporal effects. The designers therefore are required to repeatedly translate input information from time to space, and translate from space to time for relevant output. Any temporal operations in between must be performed through space-only transformations. It is no wonder these unfortunate software designers often make mistakes.

Best regards,
CharlieM
 
James Ingraham wrote:
>> If you write software the traditional way and "compile" it to hardware you'll
>> still have the exact same propensity for bugs. And somehow I doubt that ink-jet
>> printed circuits are going to be up to the standards that the big automation
>> companies have for making hardware robust and reliable.

Charles Moeller wrote:
> The biggest problem designers have with control software is the requirement to
> repetitively translate to and from the space domain.

How do you define the space-domain and the time-domain ?

In my understanding is a space-domain defined by a "space" which contains a set of different system states. It has nothing to do with a memory or a list of instructions. A time-space is a "space" which provides a set of events. The temporal logic defines e.g. the relationship between state changes and events, IMHO.

The understanding of physicists of the time-domain and the space domain is completely different ....

> Logic, software, and computational prowess are concentrated almost wholly in the space-domain.

All of the different temporal logics are not based on logic? Processing of data at an individual system state creates data changes ... that means events!

> There is no temporal logic that is native to the time-domain. Data is taken from
> the space- and time-domains (or space-time domain)

... what is a space-time domain??

> of the real world via sampling and selection and filed in memory (space-domain). A
> list of instructions (space-domain) is applied to the data and it is processed by means of
> Boolean logic operators (all space-domain transformations that can be laid out in row- and column-truth-tables).

A list of instruction represents an Algorithm. Some algorithms doesn't terminate ... that means the results can't be laid in a finit table.

> All reference values, if any, are discrete.

> One of the major difficulties faced by software designers is although they live and work
> in three-dimensional space and multi-threaded time,

... and what is a multi-threaded time ?

> they are constrained to create systems that reside completely within the space-domains
> of computers. These systems must sense and react to real world temporal effects. The
> designers therefore are required to repeatedly translate input information from time to space,

Input information are located in your "space-domain" ... what do you have to translate?

> and translate from space to time for relevant output.

... and what is the representation of a "relevant output" in time ?

> Any temporal operations in between must be performed through space-only
> transformations. It is no wonder these unfortunate software designers often make mistakes.

And hardware designer are working also in the physical space ... that means they have an additional area to make mistakes :)

Sorry for all of my dumb questions.

Best Regards
Armin Steinhoff
 
C

Charles Moeller

Charles Moeller wrote:
>> The biggest problem designers have with control software is the requirement to
>> repetitively translate to and from the space domain.

Armin Steinhoff wrote:
> How do you define the space-domain and the time-domain ?

In a typical process, the real time domain is what the physical process being controlled runs in (<b>actuality</b>: the real stuff of existence). The (artificial) space-domain is what the computers manage: memory, data, control store, instruction counter, address register, data and address busses, etc. “Bits in locations and paths for them.”

In a control system, parameters that indicate how the process is doing are repetitively sampled from sensors, digitized and stored in memory spaces. Those values are retrieved under program control and matched against one or more reference “standards.” Actions are taken to keep the process working at some defined optimum, dependent upon the results of the comparisons.

All is subject to error. The bits may be awry, the addresses may be off, or the meaning of that sterile data could be interpreted wrongly. Computation, as a means of process control is complex and adds many new components to any control scheme, increasing the risk of faults.

--snip--

Charles Moeller wrote:
>> Logic, software, and computational prowess are concentrated almost wholly in the space-domain.

Armin Steinhoff wrote:
> All of the different temporal logicsare not based on logic? Processing of data at an individual system state
> creates data changes ... that means events!

Great effort is expended to prevent time and temporal effects (change and events) from occurring and affecting computational systems. In any such design, one must adhere, for example, to setup and hold times. Operations are considered to be executed in a null-time zone, as the evaluations are ready at the next live moment (usually at the next clock pulse or instruction), which is designed to occur after any contributing settling or gate-delay times have run to completion.

Charles Moeller wrote:
>> There is no temporal logic that is native to the time-domain. Data is taken from
>> the space- and time-domains (or space-time domain)

Armin Steinhoff wrote:
> ... what is a space-time domain??

Some people like to refer to “space-time” after Einstein’s usage. For us ordinary mortals, plain “space and time” is usually sufficient.

Charles Moeller wrote:
>> A list of instructions (space-domain) is applied to the data and it is processed by means of
>> Boolean logic operators (all space-domain transformations that can be laid out in row- and column-truth-tables).

Armin Steinhoff wrote:
> A list of instruction represents an Algorithm. Some algorithms doesn't terminate ... that means the results
> can't be laid in a finit table.

Charles Moeller wrote:
>> All reference values, if any, are discrete.
>> One of the major difficulties faced by software designers is although they live and work
>> in three-dimensional space and multi-threaded time,

Armin Steinhoff wrote:
> ... and what is a multi-threaded time?

I refer to the existence and influence of objects and people on intersecting world-lines.

Charles Moeller wrote:
>> they are constrained to create systems that reside completely within the space-domains
>> of computers. These systems must sense and react to real world temporal effects. The
>> designers therefore are required to repeatedly translate input information from time to space,

Armin Steinhoff wrote:
> Input information are located in your "space-domain" ... what do you have to translate?

Charles Moeller wrote:
>> and translate from space to time for relevant output.

Armin Steinhoff wrote:
> ... and what is the representation of a "relevant output" in time ?

When the computer data is represented by a physical presence (output) in the real world (join the real time domain).

Charles Moeller wrote:
>> Any temporal operations in between must be performed through space-only
>> transformations. It is no wonder these unfortunate software designers often make mistakes.

Armin Steinhoff wrote:
> And hardware designer are working also in the physical space ... that means
> they have an additional area to make mistakes :)

Yes.

Best regards,
CharlieM
 
C

Charles Moeller

Bill:

>> Charles said: "My thesis is that the problems of software can be cured by
>> smarter hardware"

Bill said:
> That is an interesting topic, it seems to me that the typical machine/assembly
> code has not made any great advances in decades.

The fundamental logic has not changed much either, nor have computer activities. All higher-level computer languages (i.e., in software) are ultimately decomposable to, hence built up from, sequences and combinations of the Boolean operations (AND, NOT, and combinations) and STORE. In machine language, those operations are used to determine explicitly: a) the locations from which to acquire the numerical or conditional operands, b) what Boolean operations to perform, c) where to put the results, and d) the next step in the program. Every step is, and must be, predetermined. At bottom, that is all a computer can do.

AND, NOT, and STORE. That’s three words. Imagine writing a newspaper article (or describing a dynamic process) using repetitions, variations, and combinations of only three root words. So few allowable words or operators (simplistic logic) forces structural complexity and is one of the reasons that software is troublesome. We can simplify the code by having more sophisticated primitive operators in the foundation logic, especially in the time-domain.

If there are but few basic words or operations in any language, then it takes lots of them to put together a process description, or story. Sentences may get very complex due to the repetition of those few words/operators in existence. My approach to a more robust and healthier logic system was to identify the words and operations to expand the logic experience, with emphasis on the relations of time. Additionally, I devised a temporal logic that is native to the time-domain, apologies to A. N. Prior. Conventional logics must translate temporal-domain signals into data suitable to the space-domain where they can be manipulated by static operators. PTQ does not need to translate from the time-domain to the space-domain for logic operations, then translate back to the time domain for useful output. PTQ can determine the truth value of temporally related events and conditions on-the-fly, as they occur in real time, with resultants available within a few gate-delays.

> An interesting idea is silicon that has a high level language as its native
> machine code.

My process-control language specification of a process translates directly to hardware that monitors and controls the process.

Best regards,
CharlieM
 
Top