In Microcomputer-Based Instrument Model, Part 1: A General Instrument Architecture we discussed Instrument Architecture . And now on to Part 2.
Without a clear understanding of the problem definition, we are likely to solve the wrong problem. This applies to instrument design as much as to any other engineering project. A clear definition — a complete product description — results from a clear overall view of the subject-matter, and this broader understanding is a good philosophical understanding. Usually, engineers have little to do with “foolosophy” and when the word is used in engineering meetings, it usually means “opinion” instead. Here it means ontology (what a thing is in itself — a part of metaphysics, or what is real) and also epistemology (what is true, or how we know and how we know we know).
Engineers often avoid philosophy because an incompetent handling of wider issues often degenerates into an exposition of faulty logic, unquestioned premises, and more heat than light. It does not contribute to project progress. Many engineers steer clear of it. Here we will with some caution venture back in, only to show that a well-developed engineering outlook is large enough to encompass a few philosophical considerations. While philosophy is no substitute for technical or scientific know-how, it augments it instead. This can clearly be seen, for instance, in modern physics; to this day, the philosophical interpretation of quantum mechanics remains an unresolved issue. The equations correspond to observation, but what do they mean? There are at least ten different schools of thought about this. Physics and philosophy overlap. (Physics and Philosophy is also the title of a book by Werner Heisenberg from Harper Torchbooks, 1958.)
Engineering philosophy applies to something as mundane as measurement instruments when they are considered from a larger viewpoint. In the first article of this series, a general instrument architecture was proposed, and now it will be investigated more thoroughly. The diagram of it is repeated below, and will be unraveled and expanded to hopefully result in a clear view of what instruments are about. Some philosophy is involved.
We start the venture by considering the flow of cause and effect in the general measurement instrument. Nothing happens of consequence until the user chooses to actuate some control on the front-panel (which can include serial ports, etc.). However, it is important to not miss something that happens even earlier; the user has formed abstract ideas about the device under test (DUT), which, like the user, is outside the instrument in the measurement environment . For instruments to have any meaning (purpose), there must be at least the user and DUT, both not a part of the instrument. And the instrument would probably not exist if users did not have abstract notions in their minds about reality, in this case the DUT, and desires to know something about the DUT.
What is often expected of instruments is not the mere acquisition of electrical quantities, but the extraction from them of some more abstract quantity. An impedance meter is expected to display impedance, a quantity that is an abstraction from raw electrical data at the interface between the instrument core (the non-μC part of the instrument electronics) and the DUT. Even oscilloscopes present to the user an abstraction from the reality of the waveforms being acquired in that only snapshots (aligned with each other by the trigger system) are shown. Vast segments of the actual waveform are missed and not displayed, leading DSO designers to capture more of it with “digital phosphor” acquisition methods, for instance.
The instrument architecture diagram above can be flattened by rotating the left and right arms upward until they are in line. Then the traffic in each direction is separated into distinct blocks and unfolded with more rotations. The result is the serpentine diagram below, folded into four rows to fit the page. At the extreme ends of the rather long unraveled diagram of cause and effect (starting top-left and ending bottom-left), is something hidden in plain sight: ideas about reality. These abstractions are related to observable physical quantities through user technical knowledge. Without this abstract world in the user's mind, Z meters and DSOs would have no reason to exist.
The four rows of blocks are, from top to bottom, the front-panel input, instrument output, instrument input, and front-panel output functions. The physical aspect of the instrument is shown between the vertical dotted lines. (The right dotted line could itself be the μC hardware.) The (horizontal) software levels can be conceived as mirroring the levels of reality outside the software. The circuit-level software involves I/O routines with semantics that are of “objects” of the front-panel or instrument core electronics. Its scope is constrained to that of front-panel and instrument-core circuits and consists of processing close to the acquired and generated waveforms of the front-panel and instrument core. Its processing is an abstraction process, taking (for command input processing) raw encoder and button state bits and interpreting them as basic front-panel instrument commands. These are passed on to the menu processor.
Its scope is constrained to instrument-model semantics, though its processing organizes how the user relates to the instrument model volitionally. That is, the menu processor addresses the user's desires about how to achieve instrument functions by organizing the user's invocations of those functions. Its language is at the same level of conceptual abstraction as the next block in the second row, instrument function processing. What is different is that the instrument function processor is not concerned about the user but about how to make the instrument core perform the commands received as inputs from the menu processor. The second row of right-to-left blocks is about how to make the instrument output be in accord with the invoked instrument menu command.
In the third row, the DUT responds (with or without prodding from the second row) and its response drives a series of functions that convert, interpret, and abstract until at the highest level of software, the “objects” of concern mirror those of the measurement environment. Its semantics are about measurement, not instrument circuit behavior as found in the circuit-level software. Similar reasoning applies to the fourth row, which inputs measurement-oriented information, reduces it to a lower level of abstraction as device-oriented display data, outputs it to the front-panel hardware which outputs visual effects for the user. These are interpreted by the user as measurements — and we are again in that seemingly nebulous mental world of ideas. At the very beginning and end of this chain of cause and effect is the mind of the user, invoking and then reflecting upon measurements that are abstractions useful in characterizing the DUT.
What good is this general instrument model? Can it be used to design better instrument architecture? Hopefully so. At least, I am testing that hypothesis in designing a wide range of medium-performance (that is, most widely used) instruments to which this model is being applied. By decomposing the instrument functions into these distinct blocks, it is possible to better organize what the overall software and hardware design tasks should be and how to regard them conceptually.
As for the philosophy, you probably noticed that I used dotted lines with arrows in relating the physical aspects of the system to the mental aspects. Are mental constructs real? It is an ontological question, like asking whether software is real. A reductionist computer engineer could explain the operation of the μC purely in electrical language, without once referring to software at all. He might say, “Look, all that is really going on here is just electrical phenomena. I have explained all the circuit behavior without having to bring in any software hocus-pocus.” Yet such an explanation would generally be regarded as lacking the insights, simplified understanding and conceptual power that recourse to software concepts bring us. It is like explaining a sign as just so much paint on sheet metal, and nothing more, without once referring to the meaning or appreciating the conceptual power of its message.
Before Galileo's explanation of the solar system triumphed, the planetary phenomena could be explained in terms of the more complicated epicycles. Yet by shifting his frame of reference from the earth to the sun, a satisfyingly simpler and clearer result was obtained in spite of the observable fact that the sun passed daily in a circular arc across the sky. Both Galileo and his opponents had the same data but different epistemological frameworks in which they formulated their theories. Of course, at the root of the argument back then was a difference in biblical understanding, leading Galileo to make the apt remark, “The Bible tells us how to go to heaven, not how the heavens go.” People still argue about that topic today, though for instrument architecture, it seems less heated. Yet the question persists: Do ideas properly belong as a part of this overall instrument model? That is an epistemological question for you to answer.