After Software, What's Next?

V

Vladimir E. Zyubin

Vladimir Zyubin wrote:
>> As to me, I think, it is more easy to wait for a patent or a
>> publication about the "chrono-synclastic" solution.

CharlieM wrote:
>Thank you for your patience.

Charlie: I really wish you the best, and I have no problem with the discussion, the joke was about the word "wait".. to demonstrate my ability to operate in terms of a temporal logic. :)

best regards,
Vladimir
 
I agree with "Julie In Austin". Most problems I've dealt with in other peoples software is due to other factors rather than the technologies/capabilities of the system. My career is seemingly split between creating my own software and updating/rewriting/documenting other peoples programs. Sometimes a person will come through a company and pull one program out after another and then some poor fool is stuck maintaining it 10 years later after the original author has either found another job or got canned. It seems that some folks don't even like updating their own software and pass the buck to the next guy. Until management starts caring about technique/style/documentation/quality in software this problem will persist no matter what the technology is.

KEJR
 
C

Charles Moeller

Vladimir:

Vladimir Zyubin wrote:
> Charlie: I really wish you the best, and I have no problem with the
>discussion, the joke was about the word
> "wait".. to demonstrate my ability to operate in terms of a temporal logic.

Right. WHILE you WAIT, we can CONTINUE to enjoy the discussion.

Best regards,
CharlieM
 
C

Charles Moeller

Armin:

Armin Steinhoff wrote:
>>> Every FPGA based control system is software based ... this software is
>>> called firmware which can includes lots of faults.
--snip--
> The software is represented as links between the gates of the FPGA ... if one
> link is wrong the hardware will not work as expected.

It may help you to think of the interconnections as hardware switch settings. These can just as well be fuse links or non-volatile memory cells (vs. SRAM) that are selectively blown or set to make the interconnection pattern.

Best regards,
CharlieM
 
Armin Steinhoff wrote:
>>>> Every FPGA based control system is software based ... this software is
>>>> called firmware which can includes lots of faults.
> --snip--
>> The software is represented as links between the gates of the FPGA ... if one
>> link is wrong the hardware will not work as expected.

Charles Moeller wrote:
> It may help you to think of the interconnections as hardware switch settings.

The interconnections are defined by software ... e.g. by values stored in SRAM cells of the FPGA. The means the software is distributed over thousands of cells of the FPGA device.

And this software defines the behavior of the hardware .... without that software the hardware of a FPGA is dumb piece electronics.

Best Regards
Armin Steinhoff
 
C

Charles Moeller

Vladimir,

CharlieM wrote:
>> I object to the method of TM, shared resources, and software because it is several steps removed from reality.

Vladimir Zyubin wrote:
> OK. The "TM method" is bad, but the modern computer architecture does not
> prevent to use other methods, based on lambda-calculus, for example.

Lorenzo Church developed lambda calculus, a mathematical system for defining computable functions. It is a model of computation equivalent in power to (and has the limitations of) the Turing machine.

CharlieM wrote:
>> I have devised a better way of specifying processes that can be directly implemented in hardware that
>> performs immediately in a stimulus-response manner. My method depends only upon precise specification
>> of the actual process in terms of the allowable PTQ operators.

Vladimir Zyubin wrote:
> Well, I do not know what the PTQ operators are, but it does not matter,
> because the right question is, can the PTQ operators be implemented on the
> modern computer architecture or cannot.

Every prior method of specifying control systems (RTL, fuzzy logic, neural nets, etc.) has ultimately been implemented in or through computers, thereby assuming the impediments and shortcomings of the Turing paradigm (TMs with shared resources and software).

PTQ is not a programming technique or language, it is a hardware language that can transform a process specification into hardware that can monitor and control that process. PTQ is a different method of specifying and implementing processes and process controllers. It does not use a fixed architecture, but is free-form and allows a selection of defined special logic elements. That’s why a “sea-of-gates” FPGA is especially suitable for PTQ implementation in hardware.

PTQ operators do not need the massive and complex computer architecture for support, as its operators are not “interpreted.” They convey the literal meanings of their names, which activities are recognized or enacted in their corresponding hardware logic elements and architecture. Simulation of these operators/elements/functions by means of computer architecture and software would cause the loss of their benefits by orders of magnitude.

Vladimir Zyubin wrote:
> If the PTQ operators can be implemented on the architecture, ...

Doing so would be to lose most of the benefits of PTQ and assume the impediments of computation.

Vladimir Zyubin wrote:
> If they cannot be implemented, then it is a real academic >result, and you need no to think about
> money and job at all, because you could earn a lot of money as an invited lecturer.

I would like to do some of that.

Best regards,
CharlieM
 
C

Charles Moeller

Ken:

> I agree with "Julie In Austin". Most problems I've dealt with in other peoples software is due to other factors
> rather than the technologies/capabilities of the system.

--snip--

> Until management starts caring about technique/style/documentation/quality in software this problem will persist no
> matter what the technology is.

I also agree with both you and Julie In Austin, and an article in January 2012 Control Engineering states that "60% of all failures come from design."

The point I have been making is that the Turing paradigm (a very complex method) is not the optimum method for real time, time-critical, and safety-critical control systems.

Best regards,
CharlieM
 
C

Charles Moeller

Armin,

--snip--

> IMHO ... the subject of this communication thread is wrong. There
> will be always software necessary even if you program "programmable hardware".

You have a point, Armin. I agree there will always be software.

Next time the thread will be more appropriately titled: "After run-time software, what’s next?"

Best regards,
CharlieM
 
W
CharlieM said:

> The point I have been making is that the Turing paradigm (a very complex method)
> is not the optimum method for real time, time-critical, and safety-critical control systems."

I think the main roadblock that you currently have is that the Turing model is all that most of us know and understand. Except for the obsolete concept of the "analog computer", which I believe is based on operational amplifiers.

As far as optimal real time digital control, the best results I have seen so far have been focused on maximizing update rates and resolution in an attempt to emulate an analog system. Think of a CD player, for instance. I think if you can get update rates and resolution sufficiently high so the output of the system looks like analog, then the rest is a "simple matter of programming".

Bill Sturm
 
V

Vladimir E. Zyubin

Bill Sturm wrote:
> I think if you can get update rates and resolution sufficiently high so the output
> of the system looks like analog, then the rest is a "simple matter of programming".

There is such a thing as accuracy (measurement uncertainty to be precise). The limit of derivative part of any PID algorithm, as the rate approaches infinity, is infinity. :)

"The faster the better" idea inserted in our brains by the idiotic realtime adds is wrong. For most control tasks, current productivity of the platforms is more than enough.

best regards, Vladimir
 
C

Charles Moeller

Bill Sturm,

CharlieM said:

>> The point I have been making is that the Turing paradigm (a very complex method)
>> is not the optimum method for real time, time-critical, and safety-critical control systems."

Bill Sturm wrote:
> I think the main roadblock that you currently have is that the Turing model is all that most of us know and
> understand. Except for the obsolete concept of the "analog computer", which I believe is based on operational amplifiers.

- and chopper amplifiers and servo systems that drive trig-functions.

Bill Sturm wrote:
> As far as optimal real time digital control, the best results I have seen so far have been focused on maximizing
> update rates and resolution in an attempt to emulate an analog system.

Hence the quest for higher and higher clock rates.
Will any speed be enough?
____

I have developed a new control technology and logic that does not depend upon numbers or computation. I am having trouble finding some organization to champion it so that China, India, or Japan do not get the benefits before USA does. The following describes some of its remarkable characteristics:

A method of physical process automation is announced that can function without microprocessors, software, clocked state-machines, or register-transfer-level devices. This “natural” method directly senses and operates on the elemental signals intrinsically bound to the process. The temporal relationships of the process activities that generate the signals are defined and determined by the character and conduct of the process. In like manner, the temporal relationships between and among the signals so generated enable direct monitoring and control of the process. This method of automata is based upon the temporal relationships of the events and conditions of the process as described and managed by the operators and formalisms of PTQ.

This new automation technology operates from DC to light-speed, has parallel-concurrent functionality, does not rely upon run-time software and is real-time and continuous-time as well as frame-freeze, and is both synchronous and asynchronous. It is safer, faster, and simpler, and costs much less to design, implement, and maintain time-, safety-, and mission-critical process-control systems (than computer- and microprocessor-based designs).

This technology includes a dynamic logic with which to express the topology of change, time-domain temporal logic operators and corresponding hardware logic elements, and a method of translating natural language (English) process specifications directly to hardware (in FPGAs) to mirror, monitor, and control physical processes. A user’s manual describes the technology and includes example control systems.

Who might have an interest in this next new thing?

Best regards,
CharlieM
 
V

Vladimir E. Zyubin

Vladimir Zyubin wrote:
>> OK. The "TM method" is bad, but the modern computer architecture does not
>> prevent to use other methods, based on lambda-calculus, for example.

CharlieM wrote:
> Lorenzo Church developed lambda calculus, a mathematical system for
> defining computable functions. It is a model of computation equivalent in power
> to (and has the limitations of) the Turing machine.

Yes, these two models of computation are equivalent, and are _different_ ...and the Lisp is successfully used on the TM architectures.
BTW, have a look at
It seems it will be interesting to you

Vladimir Zyubin wrote:
>> Well, I do not know what the PTQ operators are, but it does not matter,
>> because the right question is, can the PTQ operators be implemented on the
>> modern computer architecture or cannot.

CharlieM wrote:
> PTQ is not a programming technique or language, it is a hardware language that
> can transform a process specification into hardware that can monitor and
> control that process. PTQ is a different method of specifying and implementing
> processes and process controllers.

I am sorry, I cannot understand the state "PTQ is not a programming language, it is a hardware language". What do you mean by "hardware language"? WDYM by software language? Do you mean hardware [description] language, or what? Maybe do you just mean a "programming language"?

CharlieM wrote:
> PTQ operators do not need the massive and complex computer architecture for
> support, as its operators are not “interpreted.” They convey the literal
> meanings of their names, which activities are recognized or enacted in
> their corresponding hardware logic elements and architecture. Simulation of
> these operators/elements/functions by means of computer architecture and
> software would cause the loss of their benefits by orders of magnitude.

I am afraid, it looks like principles implemented in one of the first soviet PCs (1965)
http://en.wikipedia.org/wiki/Mir_(computer)

best regards, Vladimir
 
C

Charles Moeller

Vladimir:

CharlieM wrote:
>> PTQ is not a programming technique or language, it is a hardware language that
>> can transform a process specification into hardware that can monitor and control
>> that process. PTQ is a different method of specifying and implementing processes and process controllers.

Vladimir Zyubin wrote:
> I am sorry, I cannot understand the state "PTQ is not a programming language, it is a hardware language".
> What do you mean by "hardware language"? WDYM by software language? Do you mean
> hardware [description] language, or what? Maybe do you just mean a "programming language"?

C, Fortran, and Basic are programming languages. A programming language assumes a Turing-type machine having hardware facilities suitable to read line-by-line and execute the instructions written in that language.

Automating physical processes and their machinery can improve the costs of mass-produced products. Monitoring and controlling such machines are necessary tasks. PTQ is an alternative hardware control technology that does not use sampling, instructions, TMs, run-time software, shared resources, time-sharing, or any of the common computational means that are used to achieve process control.

PTQ is a physical process-description language (not a computer language) whose operators and functions have corresponding hardware logic elements. It does not “run” on a computer, nor is it a series of instructions. A PTQ specification results in a stand-alone logic element configuration that can replace computation as a means to monitor and control a process. If one can specify a physical process using its defined operators and functions, then one may use that process description to identify the corresponding logic elements and specify their interconnections. The resulting hardware configuration will mirror the physical process in PTQ logic as process events occur and conditions change. Any deviation from the specified process operation will cause a corrective action, a protective stop, or an alarm.

I will produce an example problem and solutions to show the difference between a computational approach and the PTQ method.

CharlieM wrote:
>> PTQ operators do not need the massive and complex computer architecture for
>> support, as its operators are not “interpreted.” They convey the literal
>> meanings of their names, which activities are recognized or enacted in
>> their corresponding hardware logic elements and architecture. Simulation of
>> these operators/elements/functions by means of computer architecture and
>> software would cause the loss of their benefits by orders of magnitude.

Vladimir Zyubin wrote:
> I am afraid, it looks like principles implemented in one of the first soviet PCs (1965)
> http://en.wikipedia.org/wiki/Mir_(computer)

Not so, as the method of PTQ is non-computational.

Best regards,
CharlieM
 
B
CharlieM said:
>A method of physical process automation is announced that can function without
>microprocessors, software, clocked state-machines, or register-transfer-level
>devices. This “natural” method directly senses and operates on the elemental
>signals intrinsically bound to the process. The temporal relationships of the
>process activities that generate the signals are defined and determined by
>the character and conduct of the process. In like manner, the temporal
>relationships between and among the signals so generated enable direct
>monitoring and control of the process. This method of automata is based upon
>the temporal relationships of the events and conditions of the process as
>described and managed by the operators and formalisms of PTQ.
>
>This new automation technology operates from DC to light-speed ...

Sounds like a good old-fashioned analogue computer to me! - but light-speed?
 
C

Charles Moeller

Bruce,

CharlieM said:
>>A method of physical process automation is announced that can function without
>>microprocessors, software, clocked state-machines, or register-transfer-level
>>devices. This “natural” method directly senses and operates on the elemental
>>signals intrinsically bound to the process. The temporal relationships of the
>>process activities that generate the signals are defined and determined by the
>>character and conduct of the process. In like manner, the temporal relationships
>> between and among the signals so generated enable direct monitoring and control
>> of the process. This method of automata is based upon >the temporal relationships
>> of the events and conditions of the process as

>>described and managed by the operators and formalisms of PTQ.

>>This new automation technology operates from DC to light-speed ...

Bruce wrote:
> Sounds like a good old-fashioned analogue computer to me! – but light-speed?

PTQ is digital in amplitude, analog in time (usually no clock).

PTQ is made up of primarily directly-ccnnected stimulus-response mechanisms, so there is no wait for "processing," or instructions to be carried out before a decision is made, so answers can come along at the speed of the motivating power used. That means at electron propagation speeds if in electronic logic elements, or at light speed if working with optical logic elements.

Best regards,
CharlieM
 
Charles Moeller wrote:
> C, Fortran, and Basic are programming languages. A programming language assumes a
> Turing-type machine having hardware facilities suitable to read line-by-line and execute
> the instructions written in that language.

> Automating physical processes and their machinery can improve the costs of mass-produced products.
> Monitoring and controlling such machines are necessary tasks. PTQ is an alternative hardware
> control technology that does not use sampling, instructions, TMs, run-time software, shared resources,
> time-sharing, or any of the common computational means that are used to achieve process control.

> PTQ is a physical process-description language (not a computer language) whose
> operators and functions have corresponding hardware logic elements.

Vladimir Zyubin wrote:
"PTQ is not a programming language, it is a hardware language"??

> It does not “run” on a computer, nor is it a series of instructions. A PTQ specification
> results in a stand-alone logic element configuration that can replace computation as a
> means to monitor and control a process. If one can specify a physical process using its > defined operators and functions, then one may use that process description to identify
> the corresponding logic elements and specify their interconnections. The resulting
> hardware configuration will mirror the physical process in PTQ logic as process events
> occur and conditions change. Any deviation from the specified process operation will
> cause a corrective action, a protective stop, or an alarm.

You mean something like that ?:

Best Regards
Armin Steinhoff
 
V

Vladimir E. Zyubin

CharlieM said:
> This new automation technology operates from DC to light-speed, has parallel-concurrent functionality, does
> not rely upon run-time software and is real-time and continuous-time as well as frame-freeze, and is both synchronous
> and asynchronous. It is safer, faster, and simpler, and costs much less to design, implement, and maintain time-,
> safety-, and mission-critical process-control systems (than computer- and microprocessor-based designs).
---- cut ---
> Who might have an interest in this next new thing?

_New_ thing is not much interesting "as is" for practical use. People, that make the decision you are looking for, are interested in the economic effect that assumes question of migration as well. IMO, now you should emphasize the profit, but difference (new principles).

If you will show that your device can easy replace a conventional PLC (e.g. Siemens S-700), and needs no additional training of the personal, and is three times cheaper, and has MTBF that is three times bigger than MTBF of the PLC, and etc., then you will find the people. No other way.

They are interested "what" they will have, "why" is a second-order question.

And maybe, it would be better to show just a niche for your solution.

A working prototype would be helpful as well.

best,
Vladimir
 
Mr. Moeller:

Finally, you have revealed some details about your invention - the PTQ engine. We know it is not based on a Turing Machine model, but we are still in the dark about its suitability to solve real process control problems.

Your claims are substantial, if they can be proven. Are you prototyping the PTQ engine anywhere? Do you have demons ratable results? Can you supply more details on the operators beyond AND and NOT functions.

We hear some rather large claims, but see no proof.

Dick Caro
Richard H. 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

Charles Moeller

Dick Caro and Vladimir,

Dick said:
> Finally, you have revealed some details about your invention - the PTQ engine.

It is not an "engine" as is the TM, but a means of assembling concepts in free-form to suit the physical process being monitored and controlled.

On the matter of concepts: Predators have an inborn tendency to chase that which scurries, runs, or drives away (a commonsense description of prey). (Dogs therefore chase cars unless trained out of it.) Predators also have a proclivity to toy or play with what they catch. Guess what: the “toy” breaks and leaks blood --- yum, yum. A simple instinctive trait sets the stage. Concepts come later with experience and improve the odds of successful hunting.

Our logic languages have not evolved in pace with our human conceptual abilities. We can think on dynamical concepts such as motion, continuity over time, and other concepts that include the inherent notion of change (there is no perception of time without change). Our formal logic, however, can only describe static (timeless) conditions, or if dynamic ones, they must be able to be characterized by static, timeless labels. These are capable of being manipulated by static transformations or translations performable via lookup tables (the Chinese Room analogy).

For example, the concept “is raining” can be held as a label and matched for truth value to various other labels describing the weather (“sun is shining,” “is foggy,” “is snowing,” “is raining”) until one is found (or happens) which matches the specified statement. This is not dynamic logic, it is only static logic used as a poor substitute for a proper dynamic logic. A proper logic would examine the environment, determine the process underway, and assign the appropriate term(s).

The Boolean logic used in our computers is no less static than is predicate logic, propositional logic, first-order logic (FOL), or the like. Even Boolean-sequential logic is a prescribed series of static logic operations (an algorithm) performed at the tick of the clock or by instructions in step-by-step fashion. Informal Boolean-sequential logic recognizes only one action or activity: STORE, which is used to memorize a state or condition, or to convert an event in time to a value and place in memory (time to space conversion).

My improvements in logic decrease the necessity to abstract dynamic situations to a series of static pictures or states. PTQ does this by enabling duplication of event relationships in the domain of native time (in which all pertinent events happen in an ongoing process). Admittedly, my logic language and algebraic notation is an abstract representation, but it is a representation that is closer to reality than is the common practice of pegging the dynamic activity to a series of static pictures. Except for a straight-forward recording of events in real time, the only acceptable means is the linear-sequential one mediated by clocks and software instructions.

Under the present usage, logic can’t capture “continuity” or “persistence” as themselves, but only as static labels. This is because there is nothing in the logic that is either continuous or persistent. Everything is relegated to static labels in individual frozen frames. The labels are managed in much the same manner as is the manipulation of tiles or dominoes on a plane surface or as is mail being sorted to a grid of stacked cubbyholes.

Regarding motion, physics can describe velocity or acceleration of a body at a point, or as an average over an interval. Any analysis or evaluation to arrive at a descriptive value, however, is a static transformation that results in a discrete, or fixed, number. The Newton-Leibniz calculus can describe the whole dynamic trajectory, but whenever evaluated, settles on a discrete, static numerical value.

So you can see that neither our logic nor our mathematics has evolved in pace with our human conceptual abilities. I am doing something about the logic aspect. Someone else will have to devise the mathematics to follow these new logical concepts. (more to follow)

Best regards,
CharlieM
 
Top