Microcomputer-Based Instrument Model, Part 1: A General Instrument Architecture

One of the strategic design considerations for integration of microcomputers into measurement instruments is how to relate the electronic circuits of the instrument to the microcomputer (μC) and user interface. A general model of μC-based instruments is shown below in block diagram form:

This model is one of a conceptual hierarchy, having distinct levels that increase in abstraction at higher levels. For both the instrument hardware level and that of the environment from which measurements are to be derived, the quantities are all electrical. The circuits divide conceptually into two kinds because the instrument interacts with two different parts of its environment: the electrical phenomena being measured and the instrument user.

They are, of course, quite different, yet both interact with the instrument through either electrical interactions or, in the case of the user interface or front-panel , electromechanical or optoelectronic interactions. The instrument has both front-panel circuitry for interacting with the user and also a core of circuits that perform instrument functions. For instruments controlled from another computer through a communications link, the front-panel is partially transferred to the remote computer.

The instrument core is largely analog circuitry with digital circuit support for instrument settings: parameters relating to instrument structure such as ranging and modes of operation. At the circuit level, these are ADCs, DACs and digipots, and bit I/O lines that set the state of switches, multiplexers, and transistors. The front-panel circuits are typically LCD or LED displays, pushbuttons, and encoder knobs (“digiknobs”). For both of these electrical interfaces, μC I/O electrical functions are involved.

Software is also organized in the instrument abstraction hierarchy with the lowest, most concrete level being that closest to the electronics. This device-driver software is highly μC-dependent and also depends on the instrument core (left side of hierarchy) and front-panel (right side) implementations. It has the highest bandwidth of the software levels in the hierarchy, and its routines are sometimes written in assembly code for speed and are often interrupt-driven. This circuit-level software configures and delivers bits for instrument settings and acquires raw data from ADCs along with digital bit states (such as error flags indicating overrange) as inputs to the μC. On the front-panel side, it acquires button presses and encoder state changes.

Making measurements as such is not the goal of the instrument. Presentation of them to the user is the ultimate goal. So we also need the user and front-panel side of the folded hierarchy to perform the tasks of presenting the computed measurements and instrument states to the user while also accepting commands to be processed into a form that can be presented to the instrument-core circuits. The originating cause of instrument behavior is the user whose commands ripple up the front-panel hierarchy, over to the instrument side, and down to the measurement environment, then up the instrument hierarchy and over and down the front-panel levels to the user.

The circuit-level software functionally undoes what the instrument and front-panel circuits do; the circuits input electrical or electromechanical quantities and turn them into bits and bytes. The circuit-level software performs an inverse function on them, turning them back into the input quantities themselves, such as Enter or Escape button functions. The output of the circuit-level software is not in circuit or electrical language but in front-panel functional language. At the measurement level, the front-panel model language involves menu states and front-panel elemental functions as input from the circuit level.

On the instrument-core side, circuit-independent instrument instructions that are based on the more abstract instrument functional model (and not the particular instrument-core circuit structure ) are decomposed into circuit-dependent commands sent to the instrument circuitry to effect settings. The language of the measurement level is about instrument-core measurement functions, expressed in circuit-independent instrument instructions. The circuit-dependent software of the circuit level processes them into circuit-related functions. The circuit-level software can be thought of as mirroring in an inverse-functional way the circuit level of the instrument abstraction hierarchy.

The unprocessed instrument-core data is refined with the goal of meeting the instrument functional specifications. Measurement-level software computes measurements from the acquired electrical quantities input from the circuit level. The measurement level mirrors abstract quantities associated with the measurement functions in the instrument core and the measured quantities related to the environment. For instance, the mapping of μC ports to instrument-core control bits is a circuit-level routine. Calibration of acquired values is related to circuit imperfection, and this software routine could either be found in the circuit-level code or, for a general (offset and scaling) model of error, can be treated as a circuit-independent instrument function and be included in the instrument model. Calculation of impedance from acquired (and corrected) voltage and current quantities is a measurement-level function.

The measurement level of software involves a higher level of abstraction and has a lower bandwidth than the I/O Interface software of the circuit level. The measurement level is consequently the interrupted computing thread and also can be the more computationally intensive, applying mathematics to data for its refinement into measurements. It is often written in a high-level μC-independent language while, for speed and convenience, some of the circuit-level software is in assembly code. To port the instrument to a different hardware base, only the circuit-level software (and its development tools) changes.

The bulk of the code is thus hardware-independent, not only of the μC but also of the instrument-core implementation. This kind of functional decomposition can thus give rise to instrument cores as a category of μC peripheral that can be attached to (almost) any μC having a compiler for the language of the measurement level software. Then open-source software allows users to “roll their own” optimized instrument as a system fitting their particular needs or as a new variant for distribution to other users.

By recognizing hierarchical levels in instrument architecture, the overall design problem is simplified by decomposing design into separate, conceptually manageable levels of sub-designs. Whether the levels involve hardware or software does not matter. Decomposition into levels is conceptual, and each level involves a set of functions with well defined interactions. Function definitions at each level are in a language pertaining to the knowledge domain of that level.

At the circuit level, expect to find words of circuit language; at the measurement level, circuits are not the issue any more, and language describing measurements is found instead. Each level translates input to it into a form using the language of its domain. Each level outputs language in the domain of the receiving level. For instance, the measurement level receives commands in a measurement language from the front-panel and translates them (by applying its instrument model) into instrument-based instructions. The circuit level, in turn, translates these into instrument settings as outputs, causing electrical activity effected by software I/O instructions on ports. The ports “speak” in electrical language to the instrument-core circuits.

The modular functions are organized hierarchically because each higher level takes input from the lower level and applies model-based constraints to it. Accurate electrical quantities output by the circuit level, for instance, are more abstract than raw data coming out of an ADC. And measurements, with numbers and units, are more abstract than the electrical quantities from which they were derived at the measurement level. Measurement functions constrain the interpretation of the electrical variables, resulting in the more abstract measurements.

The same basic architecture could be used to design motor drives as well as instruments, though motor-drive and instrument models apply different constraints to data because they consist of quite different functions. The levels are modular — that is, functions have defined interfaces to adjacent levels. Just as structured code modularizes control flow in software, modularization of instrument functions conceptually manages complexity and reduces design error by specifying interactions among functions. Each set of functions comprising a level uses the same language with a vocabulary of words pertinent to the domain of that level.

In summary, instrument design decomposes strategically into two quite different hierarchies, that of acquiring measurements (left side) and also of presenting them to and accepting requests for them from the user (right side). Half the design involves how best to interact with the electrical environment under test while the other half concerns how the instrument interacts with humans or other computers programmed by them. Each of these design problems can be reduced in complexity by decomposing the overall task into a conceptual hierarchy of tasks, each level of which is sufficiently complicated in itself.

2 comments on “Microcomputer-Based Instrument Model, Part 1: A General Instrument Architecture

  1. Vishal Prajapati
    September 13, 2014

    Modularity is the indirect key to success in the market. It drastically reduces the time to market. So, rolling out new instruments or model one after another changing the trivial functionality to suit the exact application is the key stay fresh in the market.


    Another benefit by making the software as independent as possible is that development time is drastically reduced. Which makes it easy to customise the instrument for special needs. In short the modularity is the key to success in the market and may be the survival key also.


  2. Netcrawl
    September 13, 2014

    @Vishal good point, the key challenge facing engineers today is to minimize or reduce the time taken for the design and optimization of components. Many times the software have become the bottleneck in every design, its probably one of the biggest key factors contributing to the output failure

    Making the software independent is also a good idea, seek an independent software architecture and strategy advice, a small amount of money spent on an independent assessment from a qualified consulting firm can prevent a major mistake or disaster.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.