Software is Mostly Unnecessary

gosh! this is an awefully long discussion note.Time consuming to read through, but anyways. Let me put it this way. Hardware is just like a human body or pound of flesh you could say that has no skeleton or backbone. Software can be likened to that skeletal framework or backbone and what makes the human body functional. Hardware by itself is useless in most cases. Software is very necessary because even though some people dont see the good in it. It actually plays God to any hardware...directing, channeling,scheduling, predicting, etc all that the hardware will do, so that its functionality is successful. Imagine sending a space shuttle to space without any software! that being said. I shouldn't say any more on the topic. The hardship or complexity associated with software is a gift to ensure efficacy in every way!

Before software on hardware there were calculators of many types, both analog and digital, even one from ancient Egypt that calculated the positions of the sun and moon. All of those early machines were hardware-only. As late as 1965, NCR (National Cash Register) was training their technicians in maintenance of equipment having 300 to 1,000 mechanical parts and no software.

Jacquard in 1801 used punched cards for his automatic loom, a purely mechanical apparatus. Lovelace (1843) and Hollerith (early 1900s) moved the punched-card technique into data-processing. Turing, in 1936 provided the theoretical foundation for a system of computing that required software, and a decade or so later von Neumann described the architecture of hardware facilities that became our bus-organized modern computers.

Are you of the opinion that Turing machines (TMs) with shared resources and software is the end of that line?

Do you think that nothing better will ever be invented, that the present situation is the ultimate in programmable/configurable hardware?

Software are 200% necessary

software is needed in the CPU to execute the commands (micro code), at boot up , always.

Without software you may as well have a serial box with a power cord connected to it on your desk.

In my case being a DEY (Do Everything Yourselves) the client , annalist , coder , backup personnel and coffee maker are the same person and all know exactly what is expected from them and nobody will be blamed.

For commissioned work setting the specs correctly the first time is very important.

If used exclusively, central command ultimately leads to failure. Examples are the Vietnam War and the USSR. We can kill two birds with a single stone: get rid of the CPU and software with one remedy. Control systems will be ever so much better.

I fail to see an alternative to a CPU/software combination to any but the simplest machines in your posts. No mechanical device can even remotely approach the billions of operations per second handled by current CPUs.

I do believe the availability of large amounts of RAM and other memory has led to much less carefully written software, and clearly trying to keep new software compatible with old hardware leads to extra complexity, but that does not suggest eliminating software!

You are in good company, because most fail to see an alternative but use what is easily available.

All complex machines were built from "the simplest machines."

All current CPUs' functions can be reduced to combinations and sequences of only three operations: AND (conjunction), NOT (negation), and STORE (memorize). Each of those is a simple "mechanical" operation, that was implemented mechanically in the first devices capable of logic and computation. The only miracle of modern computers is their comparatively small size, low cost, and high speed. Their fundamentals have not progressed beyond those very same primitive operations.

Your comments show that you were not explained why software was developped and why on the contraray of what you think without soft ware economically things would not be better but worse.

Let assume you have to solve a problem and you have a hardware performing perfectly. Now for whichever reason the user wants to solve a problem with a slightly changed parameter. Your eccelent hardware cannot do it any more so that you are obliged to make a new specific hardware for the new problem. And this repeats every time a new problem appears!

Using software you only change a value somewhere and your harware system can supply the solution to the new problem.

Is it now clear ?

From an other point of view have you ever thought about computing speed? Using mechanical systems will be the solution from the 17th and 18th century but not for today and tomorrow.

I mentioned that software emerged as a necessary adjunct to Touring machines. The system I am championing is a non-computational approach to reckoning for process control. Such a non-Touring system would have configurable hardware that one could easily change to suit a changed process specification.

My reference to the original analog and digital computers having been all-hardware was to show that software is not an absolute necessity. In any case, electronics has for the most part replaced mechanical and electro-mechanical components. There is no reason to go backwards: Any new system would take advantage of the latest in device technology that provides very small components and great speed of response.

I've worked a little with non-software control (see my post about railroad frogs) and it's generally awfully slow and really BIG and needs a lot of maintenance. I can't even begin to imagine how many relays, for example, it would take to do a simple integration. Now, replace the relays with transistors and it's much easier, but still pretty big. So, we can then put all the transistors on an IC and make it smaller, but how to figure out the pathways and layout? Ah, software! You could burn an eprom with toggle switches, but...?!

But, I think software is much older than Touring machines. I'm surprised Nick Name let that one slide since software began in Lyons more than 2 centuries ago. Anyway, why not just use reliable software? It owrks four mic works microsoft for micrworks.

A Touring-paradigm controller needs a minimum of say 10,000 gates. It needs both hardware and software. The software must be integrated with the hardware. It is relatively slow. It can't perform tasks in continuous time because it is based upon linear-sequential operation. Each function takes its turn while the rest wait. It is not real-time: answers come well after-the-fact. It has a fixed architecture which may not be ideally suited to the application for which it is being used. It is complex and confusing to programmers because all temporal effects must be translated into the space-domain for logical treatment, then translated back to the natural time domain for output. It is difficult to test, and may take forever to test exhaustively. (see references in my first post)

The controller I envision performing non-numerical reckoning for a factory fabricating machine or an automatic braking system or for several control systems of similar complexity, needs a few hundreds of gates. There is no software. It is fast, with 2001-era FPGA devices responding in six nanoseconds of real time (not after x-many instructions). It can perform tasks in continuous time as it operates in an asynchronous and non-clocked parallel-concurrent manner. Its architecture is especially suitable for the process it controls, as by design the controller is a simulacrum of the target process. It tests itself simultaneously and continuously and in parallel with monitoring and controlling the process. It is simple because it deals with spatial and temporal effects directly in their native domains. It is hardware, so it can usually be tested exhaustively.

And to update your parameters you need to physically change each part for each parameter. Say you have 20 hardware pick and place machines with 1,000 dynamic parameters (low but easy number).

To change products 20,000 dynamic issues will have to be assessed and say 50% changed for argument sake. That means 10,000 controllers will need changed and tweaked to maximise performance. With a CPU this is all done by changing the inputs of the program and the program gives feedback to tolerance issues for real time adjustments or repair.

I understand your frustration with software but the problem lays with the programmers doing beta work and selling it as finished product. The software makes a very flexible system that can be remotely interfaced with changes never conceived by their creators. Dedicated hardware does not have as much flexibility.

Who knows you may be on to something but you will need to produce the better mouse trap and successfully market it. So far your arguments are against the current thoughts on the matter.

An idea to get you started is make discreet components that are hardware based and can be operated by software to interface in larger tools. As you build better more complex hardware make larger combined components to replace the software driven ones. If your product is better you can document the numbers and use that to market your work.

I'm fond of Analog computing but the current paradigm considers that a waste of time.

Brad

Pick and place machines need no more than CNC, which has been around for awhile. Their supervision is another thing, which my envisioned systems would do better than any TM and software.

My particular frustration with software is in its inability to perform natively in a parallel-concurrent manner. If you were given a spec. for a parallel-concurrent machine, the only way to implement it with accepted technology would be by using many linear-sequential machines in parallel. Aside from the insurmountable difficulties in programming such a beast, the result wouldn't be inherently parallel-concurrent.

Hardware flexibility can be achieved more or less instantaneously in FPGAs.

Most giant-step advancements appear to fly in the face of conventional wisdom at first.

Your idea has merit and somewhat jibes with mine.

I have direct experience with analog computers in older flight trainers. Some of their characteristics are valuable. For the most part, digital technology will suffice for the new paradigm although one must keep digitization to a minimum. (Systems use much time and energy handling all those mostly-unnecessary numbers.)

Morning CharlieM,

I'll bite, FPGAs?

Back to analog computers, the bus width is the limiting factor of digital. When your discreet states are only two characters your bus takes up major realestate that could have been used for processing.

When I get done with a few more projects I'm going to work on a analog processor I figured out years ago. Still need to configure stacks and math counters. Not this coming year hopefully next.

Brad

Brad,

Sorry, FPGAs are field-programmable gate-arrays. These are hardware assemblies of gates that may be configured (they say "programmable") to be interconnected any which way you want. The major makers are Altera and Xilinx, but there are others.

Why process, it wastes so much time and energy. Processing, in CPUs, is conversion of one or two static frames to another static frame in machine-time. Processing in a dynamic process is in real time, as it happens.

There is a simple mechanical analog computer that integrates areas (incremental height times incremental area) called a planimeter. The ones I've used were made by K&E, the same company that made (makes?) slide rules. These devices weighed several pounds and were useful, for instance, to mechanically compute nuclear plant horsepower from charts showing volume of steam vs. time.

Why would you need stacks and counters (digital devices) for an "analog" processor? Sounds like you might be making a SAR (successive approximation register) for analog to digital conversion.

Close Charlie,

The base 80 step analog registers and memory are a bit tricky when you run 127 processors on one socket. Timing is then not so critical.

Thanks, FPGAs are interesting, the first one I checked out was by IBM and was touted as the wave of the future. It seems to me that they are better suited for design variation testing before making a mask or specialized computers for changeable specific tasks. But what do I know, it has been awhile since I was at Intel Oregon production and prototyping.

SARs could be used for I/O going to digital boards of other manufacture.

Brad

Brad,

If one wants a control system in which the architecture is flexible hardware (vs. flexible software) FPGA methodology is a natural choice.

Charlie

How do you programme FGPA-s?

With a soft package

You can use a software package or a hardware selector that sets all the required switches in the FPGA.

One should use the technology that fits the problem the best way. Software and TMs are best for numerical problems and handling data. That wouldn't change.

The new technology I have in mind would be much better for time- and safety-critical and supervisory applications. Both new and old can work compatibly in the same system.

Ok use a selector for very very simple and short tasks is feasible but what do you do with the control of a simple mechatronic positioning system with a requirement for adaptive changes of the parameters due to changes in basic loads and which has a nonlinear behaviour?

Do you stay connected to the system and interrupt it for changing every time a change occurs?

My comments are not in the direction to dis consider the advantages of FGPA I only want to stress that an absolute affirmation as you did is not valid.

Please see post #34 in this thread.

Charlie

There is a simple mechanical analog computer that integrates areas (incremental height times incremental area) called a planimeter. The ones I've used were made by K&E, the same company that made (makes?) slide rules. These devices weighed several pounds and were useful, for instance, to mechanically compute nuclear plant horsepower from charts showing volume of steam vs. time.

Of course, there are many such computers in museums. I still have an E6B flight computer, with which I can estimate flight times, fuel used, wind correction angles, etc. However, a software-based microprocessor can do all this far faster, cheaper, and with greater accuracy: pilots with access to both an E6B and a modern flight computer use the modern flight computer.

Likewise for a planimeter. The basic function of a planimeter could be applied to calculating not just areas but volumes of odd shapes like a boat hull (by adding up "slices"). But imagine the size, complexity, and cost of building such a machine. My CAD system does such calculations in the blink of an eye.

Bad software is bad, but good software allows one piece of hardware to do many things. (And even crummy software, such as the stuff MS pedals, allows us to do many things, and allows my 6-year-old computer to to many things it could not do 6 years ago, without having to change the hardware.)

The trend, over the last several decades, has been to control more with software and less with hardware. I don't expect that trend to change very much. If we threw out PLCs and went back to relay logic, industry would slow to a crawl.

Thank you for the compliment assuming that I should have known about. I do in fact but I did not want to go as far as web machines working with perforated cards. Only a few know about, I concentrated more on today's technology.

In fact I am not surprised that such backwards looking comments do appear, in Lyon the new machines were destroyed by the people not understanding the positive side of development and in two centuries mankind did not change a lot (if ever).

Unfortunately all progress is done by human beings and is subject of errors but this is not a reason to go back.

I would have expected not a return to the past but a comment for the future as: " how can we develop a programme to test software and detect errors very fast in order to repair them before the first out of factory run?" this is the path to take not drive backwards.

You know that for very complex systems with a high degree of reliability required an also complex redundancy is used based on parallel work of computers with different hardwares and each one with a software developed by a different team with different macro languages. You see how far the concern for safety is going.

At least 3 systems are used with a majority vote to detect which system could be wrong. In several airborne applications the redundancy is pushed even further as well hard as soft up to 4 or even 5 parallel running systems.

I was quite interested to find that this is where we get the word saboteur from, with the workers throwing their clogs or sabots into the machines. If you know this, fine but if you don't know it's an interesting etymology.

Billions of years of evolution...Darwinian software testing of the survival of the fittest. We are still imperfect. I'm pretty sure that what you are looking for is not going to be found in a terrestrial domain. The only thing that holds hope is quantum computing, which will use infinite probabilities to calculate the best configurations for reliability... if that is what you ask for.

I am not sure we can formulate as you did. In fact due to different influences the "memory" was changed, the configuration of the DNA if we look from this side then we could say that the "FPGA" was modified in its programme and tested for survival.

The soft for me is only the non material arrangement, the changes did affect the support.

What I look for is a way to reduce the probability of failures. In complex systems the full test is almost impossible since thre are too many possible combinations of variables with moreor less probability of occuring. So that the tests are limited for highest probability which does not guarantee the relaibility in case of less probable combinations.

Good discussion.

You are spot on for a lot of stuff...(pencil me in for my usual anti Microsnot tirade)

However there are countless small control systems operating all around us which work faultlessly (Ok certainly not the wireless router sitting in front of me which I dissabled the 'wireless' section and hard wired instead).

Think of all those Mills and Machining centres and industrial robots.
I design chemical dosing control stuff (very small fry) We've just been taken over by an italian company ...
Stuff like that exists in huge quantities and generally the software is good.
I'm forever preaching simplicity to customers who think they want PC inerconnectivity and wireless operation ... which they shouldn't need if the bloody stuff worked in the first place..

I think the key my simply lie in the size.

The smaller the code the more likely it is to be solid and reliable which is what customers really want (If they only realised it)

Please someone tell Bill Gates

Del

I con cur Del,

The KISS principle is ignored in software way to much, Micro slug included. I'm surprised some super geek has not made a simple machine language kernel that runs way better than all this overstuffed bloat ware. Rant rant rant ^_rant ...

Brad

Yes, there are as you say, "countless small control systems operating all around us which work faultlessly," but at what cost in design and fabrication resources and wasted human potential? These control systems, which employ 98% of all the billions of microprocessors (and derivatives) world-wide, could have been designed simpler and safer, with much less complexity.

The issues of safety and timeliness are not universally addressable in linear-sequential machines.

I certainly agree with your sentiments on smaller code. I'm working to reduce it to zero, but that will take awhile.

If Software was Hardware like the turing machines, real bugs would be a problem, and the maintenance is a bitc..Hassle.

if Bernhard Beckert thinks software is a hassle then delete all software and the let him make that statement again, sorry Bernhard Beckert that also means the software in your pacemaker.

and i agree everybody should program in assembly language.

Surely hardware is important. After all there wouldn't be any mind (or soul?) had there not been any body. Nevertheless, in the bottom line, hardware and software are equivalent, in the sense that they eventually implement some functionality based on physical memory and logic operations.

A specific system can implement parts of its functionality in either hardware or software units (although a minimal hardware is always necessary of course.) Where you put the dividing line between hardware and software is application specific. Generally the rule of thumb is to built in hardware exactly this part that provides the most basic and most generic functionality, and allow room for diversity, improvisation, flexibility, and above all, complexity to software, which can be easily upgraded any time in the future.

The point I want to stress here, is that the argument posed in the original text (that HW is more testable while SW isn't) is lame, because as I just explained, the separating line between HW and SW is drawn such that HW is more robust about what it does, as there is less chance of redesigning it, should a problem turns up. There is nothing intrinsic in HW, as compared with SW, that makes it more testable or reliable. It's a matter of engineering decision. Imagine the extreme example of a PC which implements a spreadsheet by using HW only. Wouldn't it need years and years of debugging before it could ever become workable?

Such mails remind me of the "vendetta" between analog and digital electronics... Surely analog design is more difficult, but an engineer would take advantage of the ease of digital electronics to create more complex things (and maybe more error prone), than what he could do by using analog techniques. Something similar holds for HW and SW.

The relative testability of hardware over software is well known.

Google "software reliability," as I did and you will get the message.

We agree that SW is harder to test than HW, only that I repeat my claim that this is not because SW has something "mathematically" different than HW. Both may be represented on paper as State Machines, for example. It's just that we usually develop a system's HW up to the point we still have to deal mostly with component errors, crosstalk, non-linearities, etc. rather than having to meddle with more complex design errors. HW has to be robust and reliable, so it is kept as simple as possible to meet those requirements within a logical development time available. After that point, SW is supposed to take over and carries out the most complex part of the system. SW is thus more complex (in most of the cases), and it has to meet added requirements for scalability, upgradability, etc. But you need to understand that this is not SW's fault, it's an engineering decision about where you put the dividing line between HW and SW.

All process parameters, whether temporal or not, are typically fixed and translated into the space domain by sampling and storing. When signals corresponding to process events and conditions are so plucked out of their normal space-time reality, they become mere shadows, stripped of their natural context. They become individuated symbols—numbers or truth values—without any direct association to each other or to the process from which they came. They are just values in memory that can be identified primarily by their locations. There is no intrinsic meaning in those symbols. Any meaning intended must therefore be interpreted and assigned by the programmer, in the software or code. This method works well for static problems of symbol translation or transformation, as was theorized by Alan Turing. A physical process to be controlled that has a dynamic or evolving aspect to its progress, or that could suffer a random failure of component or signal, is quite another story altogether.

Charlie

Every controller specification could be graced with safety, reliability, and real-time operation. Clear specifications, easy design, and an architecture especially suited to the application would be nice, too. These attributes should come at nominal cost, as well.

As I mentioned in my first post in this thread, software can't do anything by itself. All memory, logic, and arithmetic are performed in hardware. ROMs, DRAMs, S/R F/Fs and rotating disks are all hardware. Hardware design is simpler and its failure modes are well-known.

Hardware design and infant mortality errors can be caught in test, while software errors can be hidden for years, only to surface when a new use of the system becomes popular.

Even the hardware has become more complex due to the Touring paradigm it supports, as it is burdened with ever-more complicated software.

The reason that software on hardware is the usual choice is because no one has provided a better alternative. That's what I intend to do.

Charlie

I'm just learning some SQL.. I was wondering how you implement a relational database in hardware?, and then query the database based on varying inputs? The company I work for has spent a million dollars on a MRP system..

maybe we could do one of those in hardware.. Quoting, Design Engineering, Documentaton Control, Inventory Management, Scheduling, Process Control, Quality Management, Technical Literature, Corporate Graphics, HR, Accounting (AR & AP & GL), and of course, company email / mailmerge... It should only take you a year to encode all that in hardware. oh, of course, there is no operating system, so you will have to cover all that too. I like my reports to be in a data reusable format, and I prefer web-enabled engineering collaboration, with the 3D solid modelling package and FEA module.. which you will also have to make...

Let me know when you are done. Then we can begin the 2 year process of data modelling to fit our corporate processes. After that, of course, we are involved in continuous improvement, so everything must be able to be modified and improved.

I'm not doubting at all that you can do this.. If you can, then we can all benefit from the high performance of hardware applications, and Microsoft can go suck itself dry. We'll have MicroHard instead. You will need an army of hardware designers.

Chris

Ho hum ...

I've already inferred the data-dominated portions of a system would be best handled by data-processing technology, while the safety- and time-critical elements can be more properly managed by sophisticated operations appropriate for the real-time domain.

Once again: the best physical process control-system design would incorporate both the new and the old technologies instead of exclusively depending upon the Touring paradigm (shared resources on fixed architecture timed by software).

Charlie

Okay thanks,

I can't find your inference though..

I'm also pretty sure hardware designers and chip desginers use cad systems to design...everything.

Your title is "Software is mostly unnecessary" I would point out that a lot of process control is performed by PLC's using ladder logic. this is fast, reliable, and amalagamates the best of both approaches.

Process control is not a large portion of the world of computing, and therefore, i think you should have put further qualifications on your title. As it stands, you are already agreeing, it is not true.

If you said 'process control software' or 'realtime software', I would completely agree.. small subset of the world of computing.

chris

I'll help you:

I was explicit in post #25 about data-processing vs. controller managerial tasks (and other real-time requirements) and that one should use the appropriate technology for each.

The ladder logic controllers (before PLCs) had no software. I know because I was there.

Embedded process control is the main use of microprocessors, as I mentioned in post #16. More on that:

The cure for control software: if nothing is done, the created world of control-electronics and software will not end, but go along as it has. There is an opportunity, however, to correct, fix, and heal the software crisis in the realm of dynamic process control. An improved system for controlling physical processes would be desirable. Needed is a smarter, more sophisticated, dedicated, flexible, asynchronous parallel-concurrent system of hardware logic that can take the place of the shared-resource hardware-software combination used now in physical-process controllers. (The embedded controller market now encompasses 98% of the universe of microprocessors and derivatives.) The new system should have a method of creating or synthesizing functional dynamic logic designs from behavioral specifications in a natural language such as English.

In my post #1 on this thread, in the first sentence of the third paragraph, I identified my target as embedded control systems. This whole discussion has been about physical-process control-systems. I'm sorry you misunderstood, and I hope this post makes it all clear to you.

You and others may have the impression the whole world is all about software, but that isn't necessarily so. There are other alternatives. You just haven't been exposed to them yet. The success of the software industry, producing billion-dollar corporations and billionaires, is not an indication of its appropriateness—only that there hasn't been a viable alternative up to this point. I hope to change that.

Charlie

Okay.

understood and agreed.

best wishes.

Good answer.

I have a book, from 1948: Computing Linkages and Mechanisms. As you say, as engineers we have the choice to use a mix of hardware and software, and software is becoming more pervasive as time goes on, for good reasons. Some of these old mechanical computers cost thousands of dollars, performed just one type of calculation, and required a good deal of skill and knowledge on the part of the operator. An engineer would be unlikely to specify such a device unless the application was really, really, extraordinary.

As you say, the fact that most engineers choose to implement solutions in software is simply a statistic that shows that software is the most suitable choice for their application.

A more realistic title for this thread might be: Software in increasingly essential.

For my vehicle, I'll use microprocessors for several functions. If I had to design custom hardware for each of these applications, it would drive my design cost up by a factor of 10 and might make the device cost as much as 50 times more, due to the low volume.

Also, speaking about metrics. One can always take good metrics and perform better benchmark tests while using software than hardware. Also, it depends on the different fields of study too. For example, in the field of bioinformatics, biocomputations or genomics. Having software or the reproduceability of data is what helps those scientist test and confirm theories and results. If everyone only had DNA sequencers that used only hardwares. How can one, beyond doubt, believe they can replicate the same research, without any hicks or without using the same sequencer? If there was an error in the hardware of the original sequencer, another scientist may not know or find out. Having machines that have exactly the same hardware and the same software enhances reliability testing, support and universality. Thats probably one of the biggest points to be considered when trying to use hardware solely-You can vouch for universal reliabilty!

I venture to say the troubles with software are in proportion to the quantity and variety of temporal issues it attempts to address. Since software is a technique organized in and for the space domain, it can address temporal issues only with difficulty.

Software algorithms managing simple operations running on shared-resource Touring machines (exclusively space-domain efforts) are best for data-dominated situations. Dynamic control systems having varying parameters are best managed by using a more sophisticated group of operators that function in the natural space and time-domains. The best solution for systems that control physical processes is to use both techniques, each where appropriate.

Charlie

The following is from National Instruments newsletter of today, regarding the testing of NASA's James Webb Telescope. (NI is, or at least started out as, a hardware company.)

"The LabVIEW FPGA Module and PXI-7813R saved hundreds of man-hours and thousands of dollars over custom chip development. In addition, we can inexpensively modify the control algorithm to improve testing, explore shutter issues, and further NASA MEMS microshutter array development."

Thanks, DK, for the info.

Using FPGAs instead of fixed TM-architecture hardware, makes the point for hardware flexibility: excellent during design, test, and modification, and good for future spec. changes and upgrades, as well.

Charlie

No! You misread it. They are using LabView FPGA (software that emulates an FPGA), unless I'm badly mistaken.

Thanks for the reminder, DK.

On the NI website, Labview FPGA is touted (broken up to emphasize the H/W aspect):

_________________________________________________________________

"The NI LabVIEW FPGA Module uses LabVIEW embedded technology to extend LabVIEW graphical development and

target field-programmable gate arrays (FPGAs) on NI reconfigurable I/O (RIO) hardware.

LabVIEW is distinctly suited for FPGA programming

because it clearly represents parallelism and data flow. With the LabVIEW FPGA Module,

you can create custom measurement and control hardware

without low-level hardware description languages or board-level design.

You can use this custom hardware for unique timing and triggering routines, ultrahigh-speed control, interfacing to digital protocols, digital signal processing (DSP), and many other applications requiring high-speed hardware reliability and tight determinism."

_______________________________________________________________________

Check it out for yourself.

In truth, FPGA "programming" really configures, or reconfigures the FPGA hardware by determining the interconnections (I/Os, crosspoints, and selected gates and higher-level hardware modules). All FPGA makers call it "programming" to take advantage of the known flexibility of software, but FPGAs are configurable hardware. As such they enjoy all the excellent aspects of hardware: parallelism, high-speed, hardware reliability, tight determinism, etc. which provides the foundation for my goals.

In summary, it is certainly possible to achieve the benefits I champion in "mostly hardware" process controllers. Notable others agree with me.

Charlie

Given your careful enumeration of control systems and safety measures for aircraft, may we conclude that:

1. Every aircraft, from the largest to the smallest, is protected by similar systems.

2. The protective systems never fail or have any faults.

3. There are no longer any aircraft accidents that are not caused by intent (9-11), operator error, or outright airframe/craft component failure due to uncontrollable causes.

If we can't conclude the above three statements, why not?

Software and the hardware it runs on are only safe to the degree that nothing fails and the design was perfect. In this age of increasing complexity, how can we guarantee that nothing ever fails. We can't, which is why computers occasionally freeze (sometimes more often) and require a system reset. The programmers can't predict every future sequence of operations and uses to which a computer could respond, or every possible hardware failure.

A linear-sequential computer is instruction-dominated, so it can't look at itself as a whole and has very few means with which to perceive something is awry (if it is). It must rely upon the data in the instantaneous frame (or two) it is addressing, whether that data is right or wrong. This is the difficulty programmers and hardware and system designers face while following the Turing machine, shared-resource, and software paradigm. There should and must be a better way than that.

Charlie

Charlie,

I'm still intrigued by what you say, and I would enjoy understanding the Non-Turing equipment you are speaking of. I certainly don't have the hardware knowledge to comment on its feasibility, and will hold my tongue. Are you speaking of computing systems that are Not clock/frequency driven? If so, how do you iterate solutions to certain classes of computing that require interation to resolve?

Respectfully,

Chris

Chris,

Just as the space-time continuum contains any and all discrete things, my dynamic non-Turing system contains computing as a small set of static operations (Boolean and memory). I write of non-computational relationships and operations that are mostly not clock/frequency-driven. Evolutions that require iterations (algorithms) can be performed by computational procedures, just as they are now commonly performed. The trick is to *not* turn all physical process parameters into numbers (after which only computational methods will suffice). The trick is to act upon and react to the elemental physical process signals using a set of more sophisticated operators rather than resort to universal digitization and computation based upon combinations and sequences of AND, NOT, and STORE.

Computation is not the only means of reckoning (monitoring and controlling) physical processes.

Best regards,

Charlie

Charlie,

I've installed and worked with lots of process control equipment in the HVAC industry. I've also worked with PLC equipment in hydraulic accumulators for the oil patch. I did get trained in boolean logic and analog circuits. and I've written tons of vb/vba software in an 'event driven' environment, so if the data aspects are excluded, then I can see that the basic event driven methodology can be applied to process control, and implement both boolean logic and direct analog feedback and control.

I think you could create modular circuits that pair feedback and control into a single hardware circuit. (eg a level sensor with built in valve control) Modularity of the components would make sales, implementation, and troubleshooting easier, than if you created complex 'motherboards' of hardware, but who knows what you have up your sleeve.

I worked for Johnson Controls, and I'm sure that they (and Honeywell and others) built lots of advanced pneumatic equipment that never used the turing model. (receiver- controllers, sensor-controllers, etc)

There was a phase of time when certain portions of the HVAC industry did use electric equipment (and still do) but when Direct Digital Controllers came around, that they were/ are based on the Turing model. Perhaps this is due to the absence of alternatives in other forms of electronic hardware controllers for process control. I think you can definitely find lots of applications for your ideas.

However, now that these process control industries are so familiar with Turing based programmable digital controllers, (esp. with touchscreen lcd monitors) you will have your work cut out for you being competetive with them.. You will have to do some serious large scale marketing to re-train 2 generations of technicians and engineers. I suggest that you start at the top, and establish your equipment with the toughest challenges available, (aerospace?) and then when you do go to market internationally, you will have something truly substantial to market with.

good work.

Chris

Chris,

You wrote:

"I can see that the basic event driven methodology can be applied to process control, and implement both boolean logic and direct analog feedback and control."

That is right.

"who knows what you have up your sleeve"

FPGAs, the ultimate in configurable hardware.

"You will have to do some serious large scale marketing to re-train 2 generations of technicians and engineers. I suggest that you start at the top, and establish your equipment with the toughest challenges available, (aerospace?) and then when you do go to market internationally, you will have something truly substantial to market with."

Historically, the newest technologies progress from the least-important usage to the most-important, not the other way 'round. Military assimilation of technology typically follows in two decades. I suspect they are still using the '386 varieties of computers.

As far as retraining goes, the task is to train out the linear-sequential thought-process and train in the parallel-concurrent one (which is our native mode of operation, after all), so that should be easy.

Thanks for the thoughts,

Charlie

I think the key to this discussion may reside in relative complexity.

Complexity is inversely proportional to determinism, probably exponentially.

When hardware and software approach similar levels of complexity, I suspect they become equally hard to fully examine.

Put another way:

I can test a given module in isolation with absolute certainty (generally). I can test a given circuit in isolation with absolute certainty (again generally); there are exceptions to both statements.

But as I combine them into larger and larger systems, I can only test what I think they should do, and what they should not do under limited sets of circumstances; as I suspect both hardware and software go asymptotic eventually. My ability to judge interactions and unexpected consequences go down with complexity as I am human.

All this said; I also recognize you are not a luddite arguing for the end of software, as many in this discussion seem to want to address.

You are proposing appropriate use of technologies; be they hardware or software.

Within that scope I totally agree with you, and most of the things that make us cram software into so many inappropriate uses are societal; not engineering.

We have lots of programmers. Programmers are (relatively) cheap. The hardware to host them is cheap. Marketing wants more features. Manufacturing wants more flexibility. We are all enamored with complexity and feature rich toys for their own sake.

I look forward to your further developments in this area.

IMHO both hardware and software have become complex in proportion to the degree and variation of the time-like problems and questions a given system must answer or address.

Software tells the hardware when it is time to do each operation. If the hardware was more temporally aware, it wouldn't need so much software, because the hardware could then sense when it was time to do the various operations it should to do to achieve the given design purpose. If the hardware didn't have to listen as much to the software (clock), it could pay more attention to itself and its various functions. It could be more "self-aware" and help itself to stay out of trouble.

The hardware should test itself during normal operations, rather than have software or a human test it off-line or during suspension of normal operation.

Charlie

Something I should have inserted way back when this was active:

Due to the difficulties you call out, software is extremely difficult to certify in the aviation community, whereas hardware is barely looked at anymore.

So the cost savings you could offer aviation would be staggering, offset of course by the sudden upsurge in demand for hardware guys.

Regards,

Emmett

Emmett,

Thanks for your vote and commentary. Do you have any supporting documentation?

Any safety- or time-critical application needs this new technology.

Probably no increased demand for hardware guys because the ones already out there will be more than enough. Hardware requirements (speed, power, etc.) will be less stringent than is already available, due to its intrinsically parallel-concurrent mode of operation.

One would think there should be many interested in a non-Touring method as the limit of Moore's Law approaches, but that doesn't seem to be the case.

Best regards,

Charlie