After Software, What's Next?

C

Charles Moeller

Armin,

CharlieM wrote:
>> PTQ is not a computer language. It is a behavioral description language that may be directly implemented in hardware
> as a configuration of logic gates.

Armin Steinhoff wrote:
> PTQ is a language directly implemented in hardware? How can you implement a language in such way ?
> I can define a language by a formal syntax and semantic ...

Yes. I can also define a language by the names of its operators and their corresponding logic element schematics in a library.

CharlieM wrote:
>> One writes the physical process description (to be monitored and controlled) as accurately as possible
>> using the operators available in PTQ.

>> The process statement so created is the schematic and architecture of the resulting hardware logic element configuration.

>> So we have process specification-to-hardware controller (via schematic entry) in one step.

Armin Steinhoff wrote:
>>> The implementation could be done with programmable hardware if the spec is compliable to VHDL, e.g.
>>> PTQ descriptions can be translated into VHDL or stated in VHDL, but that is (usually) an unneeded complication

Armin Steinhoff wrote:
> The translation is absolutely necessary for the synthesis of the FPGAs.

One of the options for design entry is <b> schematic capture</b> , described in a Xilinx CPLD document (see below).

I quote from http://www.xilinx.com/publications/products/cpld/cpld_applications_handbook.pdf:

“Schematic capture is the traditional method that designers have used to specify gate arrays and programmable logic devices. It is a graphical tool that allows you to specify the exact gates required and how you want them connected. There are four basic steps to using schematic capture:

1. After selecting a specific schematic capture tool and device library, begin building the circuit by loading the desired gates from the selected library. You can use any combination of gates that you need. You must choose a specific vendor and device family library at this time, but you don’t yet have to know what device within that family you will ultimately use with respect to package and speed.

2. Connect the gates together using nets or wires. You have complete control and can connect the gates in any configuration required by your application.

3. Add and label the input and output buffers. These will define the I/O package pins for the device.

4. Generate a netlist. A netlist is a text equivalent of the circuit. It is generated by design tools such as a schematic capture program. The netlist is a compact way for other programs to understand what gates are in the circuit, how they are connected, and the names of the I/O pins. ..."

Other options allow the designer to add new library logic elements by specifying the kind and interconnections of gates. It is this option that allows me to specify unique groupings of logic gates that perform or recognize the desired temporal characteristics fundamental to real time processes and embed those in the controller.

CharlieM wrote:
>> because the PTQ logic element library fully defines the structure (in schematic form) of each of the roster of
>> operators and corresponding hardware logic elements from which the designer can choose. Individual characteristics
>> of each logic element (gate delay, output drive, etc.) will have values typical of the device generation being
>> used (e.g., pz5032cs6a44, a Xilinx CPLD that was available in the year 2000).

Armin Steinhoff wrote:
> It's now 2012 and there are FPGAs with millions of gates.

Most of which are not needed for the simple controllers I have been writing about. Why use more than the minimum that will guarantee function and safety? More gates and more software will only increase the risk of faults.

CharlieM wrote:
>> PTQ constructions behave more similar to a dataflow, than an algorithmic model,

Armin Steinhoff wrote:
> When I correctly understand ... PTQ defines also processes, but they are based on algorithm.

PTQ describes real time processes not based upon algorithms. PTQ uses a non-registered real time dataflow-type method.

CharlieM wrote:
>> although signals are typically not registered. PTQ has temporal logic elements with an inherent sense of time

Armin Steinhoff wrote:
> In the moment I don't see any temporal elements in PTQ. Do you have a formal definition of PTQ and its semantic?

The temporal logic in the DIR contactor controller that I described was specified by "(DO SEQ DC)." This means "the Sequence: Door Open, Door Closed" A specified sequence qualifies as an identifiable temporal characteristic or quality.

Best regards,
CharlieM
 
[ clip]
Armin Steinhoff wrote:
>> PTQ is a language directly implemented in hardware? How can you implement a language in such way ?
>> I can define a language by a formal syntax and semantic ...

CharlieM wrote:
> Yes. I can also define a language by the names of its operators and their corresponding logic element schematics in a library.

That's not the sufficient way to define a formal language.

[clip]
Armin Steinhoff wrote:
>> The translation is absolutely necessary for the synthesis of the FPGAs.

CharlieM wrote:
> One of the options for design entry is schematic capture , described in a Xilinx CPLD document (see below).

> I quote from http://www.xilinx.com/publications/products/cpld/cpld_applications_handbook.pdf:

So you would translate PTQ manually to the function block display representation ? Really ??

Armin Steinhoff wrote:
>> In the moment I don't see any temporal elements in PTQ. Do you have a formal definition of PTQ and its semantic?

CharlieM wrote:
> The temporal logic in the DIR contactor controller that I described was specified by "(DO SEQ DC)." This means "the Sequence: Door Open, Door Closed"

Sorry this has nothing to do with temporal logic ...IMHO.

Best Regards
Armin Steinhoff
 
V

Vladimir E. Zyubin

CharlieM wrote:
>>> You misunderstand. PTQ is not software. It is a means of converting functional specifications, including safety and
>>> operations, to real time hardware that performs immediately according to the specifications.

Vladimir Zyubin wrote:
>> I do understand that PTQ is not a software. Also I understand that the PTQ formalism is just a formal language
>> intended to specify a control algorithm.

CharlieM wrote:
> No. PTQ does not lead to an “algorithm,” which is (from Webster’s): "a procedure for solving a mathematical
> problem (as of finding the greatest common divisor) in a finite number of steps that frequently involves
> repetition of an operation; broadly: a step-by-step procedure for solving a problem or accomplishing some end
> especially by a computer."

Alas, I see the Websters's brainpeckers don't know about control algorithms that have infinite number of steps because of unpredictable long run-time. They speak about algorithms for calculation only.

So, please have a look at http://en.wikipedia.org/wiki/Algorithm especially at the part called "Implementation".

Vladimir Zyubin wrote:
>> And please do not concentrate your attention on the word "software", please pay attention to the word "psychology".

CharlieM wrote:
> I prefer not to leave considerations of safety up to "psychology." The best way to ensure safety is to use hardware
> lockouts, which are simple hardware interlocks (if this, not that).

I must confess it seems to me you practice very disputable approach because errors in algorithms are made by a programmer (or designer if we speak of hardware implementation) not by a computer.

CharlieM wrote:
> Safety constraint 1. Door is prevented from opening if not at a floor or while lift motor is running.

> This constraint is satisfied in my elevator system by also preventing power to the door motor at any time that power
> is applied to the lift motor. This is a physical safety interlock, not a software, mental or psychological safeguard.

> Safety constraint 2. Lift motor direction is not allowed to change while lift motor is running.

> This constraint in my elevator system is satisfied by preventing change in the operating condition of the direction
> contactor while power is being applied to the lift motor. This is also a physical safety interlock, not a
> software, mental or psychological safeguard.

> Safety constraint 3. Lift motor is prevented from running while door is not closed.

> This constraint in my elevator system is satisfied by preventing power from being applied to the lift motor unless
> the door is closed. This is also a physical safety interlock, not a software, mental, or psychological safeguard.

Thank you very much. You wrote exactly those thing that I expect to see.
So again:
Your constraints do not prevent PARALLEL start of execution of the following commands:
"Lift motor running" AND "Door opening" WHILE BOTH "door is closed" AND "lift motor is not running" AND "the elevator is on a floor".

> In this case, it is hardware interlocks, implemented by:
>
> Constraint 1. Door is prevented from opening if lift motor is running (if the elevator is moving power is not
> available to open door), and
>
> Constraint 3. Lift motor is prevented from running if door is not closed (power is removed from lift motor if
> door opens).
>
> In both cases, door open and elevator moving can’t take place at the same time. Your concerns are without basis.

See above remarks.

best regards, Vladimir.
 
C

Charles Moeller

Armin,

[ clip]
Armin Steinhoff wrote:
> So you would translate PTQ manually to the function block display representation? Really??

Yes, really.
1. I write the physical process specification in terms of the PTQ operators, for which there exists a dictionary of definitions together with the corresponding hardware logic elements.

2. When all parts of the physical process have been described in PTQ terms, and the syntactical rules have been correctly followed, the design may be rewritten as a schematic of the process controller. The schematic has selected logic elements that correspond to the specification and the logic elements are interconnected according to the architecture specific to that controller. The architecture “emerges” from the specification.

3. The schematic is instantiated in the target CPLD or FPGA.

4. A test procedure is then written and the logic assembly is tested for correct function including safety measures.

5. Any design faults found are corrected and testing is resumed. This continues until the hardware and specification agree, all functions can be fulfilled, and all safety measures are upheld.

At this point, the design can be said to be complete and ready for initial field testing.

Armin Steinhoff wrote:
>>> In the moment I don't see any temporal elements in PTQ. Do you have a formal definition of PTQ and its semantic?

CharlieM wrote:
>> The temporal logic in the DIR contactor controller that I described was specified by "(DO SEQ DC)." This
>> means "the Sequence: Door Open, Door Closed"

Armin Steinhoff wrote:
> Sorry this has nothing to do with temporal logic ...IMHO.

The reason you don’t recognize <b>sequence in time</b> rather than <b>sequence in space</b> (e.g., numerical sequence) as having to do with temporal effects is that all so-called temporal logic in common use (everything with which you are familiar) is built in the space domain, through the “magic” of TMs, software, and numbers (or numbered spaces). My temporal logic is a different thing as it exists in and for the time domain and needs no conversion to and from the space domain. It is therefore more effective, efficient, and appropriate to real time process control.

Best regards,
CharlieM
 
C

Charles Moeller

Vladimir,
---- clip ----
Vladimir Zyubin wrote:
> Alas, I see the Websters's brainpeckers don't know about control algorithms that have infinite number of steps because of
> unpredictable long run-time. They speak about algorithms for calculation only.

> So, please have a look at http://en.wikipedia.org/wiki/Algorithm especially at the part called "Implementation".

I did, but Vladimir, you should have a look, also:
“In mathematics and computer science, an algorithm i/&#712;æl&#609;&#601;r&#618;ð&#601;m/ (from Algoritmi, the Latin form of Al-Khw&#257;rizm&#299;) is a step-by-step procedure for calculations. Algorithms are used for calculation, data processing, and automated reasoning.

More precisely, an algorithm is an effective method expressed as a finite list [1] of well-defined instructions [2] for calculating a function. [3] Starting from an initial state and initial input (perhaps empty), [4] the instructions describe a computation that, when executed, will proceed through a finite [5] number of well-defined successive states, eventually producing "output" [6] and terminating at a final ending state. …”

Vladimir Zyubin wrote:
>>> And please do not concentrate your attention on the word "software", please pay attention to the word "psychology".

>CharlieM wrote:
>> I prefer not to leave considerations of safety up to "psychology." The best way to ensure safety is to use hardware
>> lockouts, which are simple hardware interlocks (if this, not that).

Vladimir Zyubin wrote:
> I must confess it seems to me you practice very disputable approach because errors in algorithms are made by
> a programmer (or designer if we speak of hardware implementation) not by a computer.

--snip--

> Thank you very much. You wrote exactly those thing that I expect to see. So again:
> Your constraints do not prevent PARALLEL start of execution of the following commands:
> "Lift motor running" AND "Door opening" WHILE BOTH "door is closed" AND "lift motor is not running" AND "the elevator
> is on a floor".

Perhaps you are thinking like a computer and are subject to the same types of faults or it may be the case that you do not understand the term “hardware interlock.”

I will illuminate: A hardware interlock is designed and implemented so that, for instance, if an equipment high voltage cover is removed, the power is interrupted, thus removing the high voltage hazard that would otherwise be exposed by removing the cover. It is a case of <b>this</b> (cover removal), <b>not that</b> (high voltage present). This type of function is also called a <b>safety interlock</b>.

Another example of a hardware interlock (and is the one used in my elevator controller) is the arrangement of a power contactor or “switchgear” that can send power to one and only one of two places: a) to the door motor, or b) to the lift motor. The contact arrangement for this type of switchgear is Form C, or SPDT (single pole double throw) or equivalent. Power comes in on the common line (C) and is directed to either (but not both) the A contact (normally open) or the B contact (normally closed).

Your "parallel execution" (thinking like a computer?) does not happen.

Best regards,
CharlieM
 
> ---- clip ----
Vladimir Zyubin wrote:
>> Alas, I see the Websters's brainpeckers don't know about control algorithms that have infinite number of steps because of
>> unpredictable long run-time. They speak about algorithms for calculation only.
>> So, please have a look at http://en.wikipedia.org/wiki/Algorithm especially at the part called "Implementation".

CharlieM wrote:
> I did, but Vladimir, you should have a look, also:
> “In mathematics and computer science, an algorithm i/&#712;æl&#609;&#601;r&#618;ð&#601;m/ (from Algoritmi, the Latin form of Al-Khw&#257;rizm&#299;)
> is a step-by-step procedure for calculations. Algorithms are used for calculation, data processing, and automated reasoning.

> More precisely, an algorithm is an effective method expressed as a finite list [1] of well-defined instructions
> [2] for calculating a function. [3] Starting from an initial state and initial input (perhaps empty), [4] the instructions
> describe a computation that, when executed, will proceed through a finite [5] number of well-defined successive states,
> eventually producing "output" [6] and terminating at a final ending state. …”

Algoritm including also endless loops ... e.g. the algorithm of an finit automata. You know it as a PLC programmer.

Also FPGAs are processing step by step ... that means clock by clock. Every clock cycle is a processing cycle and the FPGA is simply just a specialized CPU.

Best Regards
Armin Steinhoff
 
V

Vladimir E. Zyubin

---- clip ----
Vladimir Zyubin wrote:
>> Alas, I see the Websters's brainpeckers don't know about control algorithms that have infinite number of steps because of
>> unpredictable long run-time. They speak about algorithms for calculation only.

>> So, please have a look at http://en.wikipedia.org/wiki/Algorithm especially at the part called "Implementation".

CharlieM wrote:
> I did, but Vladimir, you should have a look, also: “In mathematics and computer science, an algorithm
> i/&#712;æl&#609;&#601;r&#618;ð&#601;m/ (from Algoritmi, the Latin form of Al-Khw&#257;rizm&#299;) is a step-by-step procedure for calculations.
> Algorithms are used for calculation, data processing, and automated reasoning.

> More precisely, an algorithm is an effective method expressed as a finite list [1] of well-defined instructions
> [2] for calculating a function. [3] Starting from an initial state and initial input (perhaps empty), [4] the
> instructions describe a computation that, when executed, will proceed through a finite [5] number of
> well-defined successive states, eventually producing "output" [6] and terminating at a final ending state. …”

There are a lot of bad and misleading definitions we can find in the web, I do understand it. And the bad definitions can be transformed even in a more worse form as you just have shown it. I do understand it as well. Really, I can not catch why you insist that control algorithms are not algorithms.

Vladimir Zyubin wrote:
>> Thank you very much. You wrote exactly those thing that I expect to see. So again:
>> Your constraints do not prevent PARALLEL start of execution of the following commands:
>> "Lift motor running" AND "Door opening" WHILE BOTH "door is closed" AND "lift motor is not running" AND "the
>> elevator is on a floor".

CharlieM wrote:
> Perhaps you are thinking like a computer and are subject to the same types of faults or it may be the case
> that you do not understand the term “hardware interlock.”

I am sorry for the quote: "The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity." Computer cannot think, it can execute only.

As to the problem.

Parallel start of execution of "Lift motor running" AND "Door opening" WHILE BOTH "door is closed" AND"lift motor is not running" AND "the elevator is on a floor" is in full accordance with your constraints, i. e. the parallel start do not violate the restrictions.

Please do not reveal your secret about implementation. Please refrain from wordy essay about hardware interlocking... just explain (if you can) where the above statement logically violates your own constraints.

As to me the answer is clear. What about your opinion?

Best regards, Vladimir
 
C

Charles Moeller

Armin,

---- clip ----
Armin Steinhoff wrote:
> Algoritm including also endless loops ... e.g. the algorithm of an finit automata. You know it as a PLC programmer.

> Also FPGAs are processing step by step ... that means clock by clock. Every clock cycle is a processing cycle and
> the FPGA is simply just a specialized CPU.

--Can be, but is not necessarily so.

There are non-clocked circuits that are hand-crafted for a specific purpose by means of designer inspiration. We used to call these "random logic," or "glue logic." Today, these inventions can be easily configured in "sea-of-gates" FPGAs. It is this class of circuit and designs that are used in PTQ configurations.

Best regards,
CharlieM
 
C

Charles Moeller

---- clip ----
Vladimir Zyubin wrote:
> As to the problem.

> Parallel start of execution of "Lift motor running" AND "Door opening" WHILE BOTH "door is closed" AND"lift motor is
> not running" AND "the elevator is on a floor" is in full accordance with your constraints, i. e. the parallel start do
> not violate the restrictions.

> just explain (if you can) where the above statement logically violates your own constraints.

> As to me the answer is clear. What about your opinion?

Either your statements above are inconsistent or I have misinterpreted what you wrote.
You have: "Lift motor running" AND "Door opening" WHILE BOTH "door is closed" AND "lift motor is not running" AND "the elevator is on a floor"

Logically, you have lift motor (running and not running) and also (door open and closed). These pairs are mutually exclusive conditions (at the same time) but may hold at different times. Your statements are not consistent with my stated constraints. You either do not have a valid objection or you have not stated your objection clearly enough.

Please advise.

Best regards,
CharlieM
 
C

Charles Moeller

---- clip ----
Vladimir Zyubin wrote:
> Really, I can not catch why you insist that control algorithms are not algorithms.

Please, Vladimir if you will, consider that the following three statements [a), b), c)] are true:

a) Algorithms are step-by-step procedures, whether or not they are applied to control situations.
b) All problems to be solved are not necessarily control problems.

c) Some control problems are solvable by other than step-by-step (algorithmic) procedures. (Analog functions [f(x) = 2x], [f(x) = sin x], [f(x) = x^2] are examples.)

An algorithmic procedure for determining the temporal order in which two events (A and B) occur requires the signal from A to be repetitively sampled and the signal from B to be repetitively sampled. Whenever B occurs, a time-stamp is recorded in a designated location and B-sampling is suspended. Whenever A occurs, a time stamp for it is recorded in a different location and A-sampling is suspended. When both designated locations have time stamps, they are differenced. The sign of the difference is used to determine the order of events. This is a typical way for event order to be determined by computation.

A non-algorithmic method of determining the same answer with a lot less difficulty is found in the PTQ logic system, in which a special logic element with permanent connections to the monitored signal sources determines, after a reset, the order of the two received signals immediately upon receiving the second of the two signals.

The PTQ system has a number of special temporal and spatio-temporal logic elements that operate in a non-algorithmic way. That’s why collecting their operation(s) under the term “algorithm” is inappropriate. Algorithms are for computation. PTQ methods do not necessarily include or imply computation.

Best regards,
CharlieM
 
Armin Steinhoff wrote:
>> Algoritm including also endless loops ... e.g. the algorithm of an finit automata. You know it as a PLC programmer.
>> Also FPGAs are processing step by step ... that means clock by clock. Every clock cycle is a processing cycle and
>> the FPGA is simply just a specialized CPU.

CharlieM wrote:
> --Can be, but is not necessarily so.

> There are non-clocked circuits that are hand-crafted for a specific purpose by means of designer inspiration. We used
> to call these "random logic," or "glue logic." Today, these inventions can be easily configured in "sea-of-gates" FPGAs.

Every sea of gates are working clocked ...

Best Regards
Armin Steinhoff
 
C

Charles Moeller

Armin Steinhoff wrote:
--snip--
>>> Also FPGAs are processing step by step ... that means clock by clock. Every clock cycle is a processing cycle and
>>> the FPGA is simply just a specialized CPU.

CharlieM wrote:
>> --Can be, but is not necessarily so.

>> There are non-clocked circuits that are hand-crafted for a specific purpose by means of designer inspiration. We used
>> to call these "random logic," or "glue logic." Today, these inventions can be easily configured in "sea-of-gates" FPGAs.

Armin Steinhoff wrote:
> Every sea of gates are working clocked

Not so.
The referenced Xilinx document below confirms my experience that each macrocell can be used as a non-registered combinatorial function. That means an option of NO CLOCKS, no registers.

See http://www.xilinx.com/support/documentation/data_sheets/ds012.pdf page 4:

“Figure 5 shows the architecture of the macrocell used in the CoolRunner XPLA3 CPLD. Any macrocell can be reset or preset on power-up. Each macrocell register can be configured as a D-, T-, or Latch-type flip-flop, <b>or bypassed if the macrocell is required as a combinatorial logic function.</b>”

Best regards,
CharlieM
 
V

Vladimir E. Zyubin

Vladimir Zyubin wrote:
>> As to the problem.

>> Parallel start of execution of "Lift motor running" AND "Door opening" WHILE BOTH "door is closed" AND"lift motor is
>> not running" AND "the elevator is on a floor" is in full accordance with your constraints, i. e. the parallel start do
>> not violate the restrictions.
>
>> just explain (if you can) where the above statement logically violates your own constraints.
>
>> As to me the answer is clear. What about your opinion?

CharlieM wrote:
> Either your statements above are inconsistent or I have misinterpreted what you wrote.

> You have: "Lift motor running" AND "Door opening" WHILE BOTH "door is closed" AND "lift motor is not running"
> AND "the elevator is on a floor"

> Logically, you have lift motor (running and not running) and also (door open and
> closed). These pairs are mutually exclusive conditions (at the same time) but may hold at different times. Your
> statements are not consistent with my stated constraints. You either do not have a valid objection or you have not
> stated your objection clearly enough.

> Please advise.

I think the problem (cognitive dissonance) is in denotation of the sentence "Lift motor running". I interpret it as "to switch ON the lift motor contactor". And it seems to me you interpret it in some other way.

I make very simple (trivial) conclusion: parallel implementation can lead to parallel switching ON both the lift motor contactor and the door open motor contactor.

And I thought such a trivial conclusion needs no explanations at all. But it seems it is not the case.

So, again, please imagine the state of your system: "door is closed" AND "lift motor is not running" AND "the elevator is on a floor" (the values of the signals are ON, OFF, ON).

In this state you can (according to your restrictions and descriptions):
1. switch ON the lift motor contactor;
2. switch ON the door open motor contactor.

All I say is IN YOUR PARALLEL IMPLEMENTATION THESE BOTH EVENTS CAN HAPPEN IN PARALLEL (at the same time).

The problem I told about is close to the race condition problem:
http://en.wikipedia.org/wiki/Race_condition

best regards, Vladimir
 
V

Vladimir E. Zyubin

Vladimir Zyubin wrote:
>> Really, I can not catch why you insist that control algorithms are not algorithms.

Charlie wrote:
> Please, Vladimir if you will, consider that the following three statements [a), b), c)] are true:

> a) Algorithms are step-by-step procedures, whether or not they are applied to control situations.
> b) All problems to be solved are not necessarily control problems.

> c) Some control problems are solvable by other than step-by-step (algorithmic)
> procedures. (Analog functions [f(x) = 2x], [f(x) = sin x], [f(x) = x^2] are examples.)

I will, why not... and it is absolutely clear to me that calculation of "sin x" is just a step, despite of its implementation (digital, analog, mechanical, graphical, etc... even if it was got directly from an egregore... esotirec implementation :)
 
Armin Steinhoff wrote:
>> Every sea of gates are working clocked

Charles wrote:
> Not so.The referenced Xilinx document below confirms my experience that each macrocell can be
> used as a non-registered combinatorial function. That means an option of NO CLOCKS, no registers.

I was talking about a sea-of-gates of normal LUT based FPGAs ... and not macrocell based CPLDs.

So you want to build manually your algorithm within CPLDs with asynchronous working macro cell ? I can only say: have fun :)

Best Regards
Armin Steinhoff
 
C

Charles Moeller

Vladimir,

You wrote:
>>> Really, I can not catch why you insist that control algorithms are not algorithms.

Charlie wrote:
>> Please, Vladimir if you will, consider that the following three statements [a), b), c)] are true:

>> a) Algorithms are step-by-step procedures, whether or not they are applied to control situations.
>> b) All problems to be solved are not necessarily control problems.

>> c) Some control problems are solvable by other than step-by-step (algorithmic)
>> procedures. (Analog functions [f(x) = 2x], [f(x) = sin x], [f(x) = x^2] are examples.)

Vladimir Zyubin wrote:
> I will, why not... and it is absolutely clear to me that calculation of "sin x" is just a step, despite of its
> implementation (digital, analog, mechanical, graphical, etc... even if it was got directly from an egregore...esotirec implementation :)

Sin x can be output “instantaneously” as an analog value <b>as the shaft of a sine potentiometer rotates through successive angles</b>. This component was common in servomotor-based flight simulators for pilot training in the 1950s & 1960s (i.e., before the simulation field went digital).

So the method of implementation is often the key, and is my point in PTQ.

Some functions and operations that can be done simply in time-domain temporal logic hardware, rather than imperfectly in space-domain temporal logic software are: order, persistence, concurrency, and repetition. These operations and others are primitives in PTQ and all work consistently and compatibly in the time-domain with the existing space-domain primitives of conjunction and negation, and their combinations. As an example that such things do in fact exist, I have (previously) described the workings of the operation that determines, on-the-fly (as it happens), the order of two received signals, rather than after-the-fact via computational procedures on values from memory.

Best regards,
CharlieM
 
How high the risk is that the system safety will become a "week point"? Will we be able to keep up with the increasing threat?
 
Didn't read all replies, so sorry if this a repeat.

But in today's world hardware is useless without software.
Again, so long as we have a world of digital electronics we will be dependent on software.

That's just the way it works. The only thing which can be done is to embed it in a manner where it cannot be changed.
 
C
Actually I am somewhat optimistic. While automation systems today are maximally vulnerable due to their singular dependence on the least secure OS with a truly abysmal security record, the rest of the computing world is busy diversifying. Even if solutions like Android are not particularly secure, (by design) the diversity in itself raises the bar. And it is a door-opener for SELinux and others that are, or at least can be made, secure but can run much of the same software. This is happening quickly with non-Wintel blade servers and clusters adding to the absolutely crazy pace of the mobile market. As long as networks remain the primary attack vector, this unpredictability will make it much more difficult to penetrate systems. At least it will be non-trivial. Who knows, in the next 20 years, the automation folks, or more likely their customers, may begin to demand some semblance of security and Big Automation will belatedly follow the trend. A chain is only as strong as it's weakest link and it may soon be realistic and economic to design that link out. It would be good to do that before the grid goes down or even more dire damage is done, but it surely will be at least talked about after.

Regards
cww
 
RussB:

Software is a consequence of using data processors or Turing-type machines (TMs) exclusively.

The fundamental problems of TM-dominated systems persist, and will do so for as long as we insist upon solving all our problems via the Turing paradigm: shared resource hardware, software, and linear-sequential operation. I've intimately experienced four decades of "progress," including advances in the millions-fold in hardware capabilities. These meaningful improvements have resulted in Moore's Law effects that have made computing available to everyman at reasonable cost. But a software crisis exists ongoing, prior to, and since E.J. Dijkstra named it in 1971. We know that software can't cure the ills of software because it hasn't in the last 60-plus years, and not for the lack of trying.

My thesis is that the problems of software can be cured by smarter hardware.

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 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 that would expand the logic experience, with emphasis on the relations of time. Additionally, I devised a temporal logic that would be 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. My system 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.

The tasks performed in modern times by computers (and microprocessors and microcontrollers) are no longer confined to translation or transformation of one set of static symbols to another, which was the (presumed) original intent of Alan Turing. Computers are now used to monitor and control dynamic physical processes, while the computers themselves are able to perform series of only static operations as means to those dynamic ends. The memory operator STORE, used to log into memory samples of a process that changes over time, thereby performs a succession of time-to-space translations. This frame-by-frame treatment of a continuous process allows desired static operations to be executed upon the static and discrete values either recalled from memory or directly sampled from external sources. Process-control results are shifted from static repositories within the computing device to the output ports (space-to-time translation). Such approximations of temporal processes can become quite complicated, hard to understand, and in the final analysis, not indisputably correct due to processing delays. Boolean logic and Turing machine principles are anything but fundamental when they are used to deal with time.

The order of events and the chain of cause and effect are usually much more important than how many microseconds each condition lasts, or at what clock-time each occurred in a process. Physical processes start, continue, and stop. They have beginnings and existence extended in time. They end. They repeat. Several conditions can overlap, with different start and stop times for each. A natural language narrative (say, in English) can precisely describe a process having these characteristics no matter how that process twists and turns over time and in space, and all without reference to clock time, the increments of which, in any case, are arbitrary.

Given the above observations, how do we “tell the process stories” using computers with only AND, NOT, (and their combinations), and STORE? It is demonstrably difficult and it is no wonder that software production for large systems is only 50% efficient and can’t ship product guaranteed to be error-free.

Copyright 2011 by [email protected]

Best regards,
CharlieM
 
Top