3.8 Software Control

Systems Engineering

Systems engineering is the systems approach to the design and development of products and systems. As shown in Fig. 3.10, a drawing that shows the relationships of the major engineering competencies with mechatronics, the systems engineering competency encompasses the mechanical, electrical, and software competencies. There are several important tasks for the systems engineers to perform, starting with requirements gathering and continuing through final product and system verification and validation. After requirements gathering and analysis, the systems engineers should partition requirements func-tionality between mechanical, electrical, and software components, in consultation with the three competencies involved. This is part of the implementation of concurrent engineering. As also shown by the figure, software is an equal partner in the development of a mechatronic system. It is not an add-on to the system and it is not free, the two opinions that were sometimes held in the past by engineering management. While the phrase “Hardware adds cost, software adds value” is not entirely true either, sometimes software engineers felt that their competency was not given equal weight with the traditional engineering disciplines. And one last comment—many mechatronic systems are safety related, such as an air bag system in a car. It is as important for the software to be as fault tolerant as the hardware.

Software Engineering

Software engineering is concerned with both the final mechatronic “product” and the mechatronic development process. Two basic approaches are used with process, with many variations upon these approaches. One is called the “waterfall” method, where the process moves (falls) from one phase to another (e.g., analysis to design) with checkpoints along the way. The other method, the “spiral” approach, is often used when the requirements are not as well fixed. In this method there is prototyping, where the customers and/or systems engineers refine requirements as more information about the system becomes known. In either approach, once the requirements for the software portion of the mechatronic system are documented, the software engineers should further partition functionality as part of software design. Metrics as to development time, development cost, memory usage, and throughput should also be projected and recorded. Here is where the Software Engineering Institute’s Capability Maturity Model (SEI CMM) levels can be used for guidance. It is a truism that software is almost never developed as easily as estimated, and that a system can remain at the “90% complete” level for most of the development life cycle. The first solution attempted to solve this problem is often assigning more software engineers onto the project. This does not always work, however, because of the learning curve of the new people, as stated by Frederick Brooks in his important book The Mythical Man Month (Addison-Wesley 1995).

Software Design

Perhaps the most important part of the software design for a mechatronic system can be seen from the hierarchy in Fig. 3.11. Ranging from requirements at the top to hardware at the bottom, this layering serves several purposes. The most important is that it separates mechatronic functionality from imple-mentation. Quite simply, an upper layer should not be concerned with how a lower layer is actually performing a task. Each layer instead is directed by the layer above and receives a service or status from a layer below it. To cross more than one layer boundary is bad technique and can cause problems later in the process. Remember that this process abstraction is quite useful, for a mechatronic system has mechan-ical, electrical, and software parts all in concurrent development. A change in a sensor or actuator interface should only require a change at the layer immediately above, the driver layer. There is one last reason for using a hierarchical model such as this. In the current business climate, it is unlikely that the people working at the various layers will be collocated. Instead, it is not uncommon for development to be taking place in multiple locations in multiple countries. Without a crisp division of these layers, chaos can result.

For more information on these and many other topics in software engineering such as coupling, cohesion, and software reuse, please refer to Chapter 49 of this handbook, Roger Pressman’s book Software Engineering: A Practitioner’s Approach 5th Edition (McGraw Hill 2000), and Steve McConnell’s book Code Complete (Microsoft Press 1993).

3.9 Testing and Instrumentation

Verification and Validation

Verification and validation are related tasks that should be completed throughout the life cycle of the mechatronic product or system. Boehm in his book Software Engineering Economics (Prentice-Hall 1988) describes verification as “building the product right” while validation is “building the right product.” In other words, verification is the testing of the software and product to make sure that it is built to the design. Validation, on the other hand, is to make sure the software or product is built to the requirements

from the customer. As mentioned, verification and validation are life cycle tasks, not tasks completed just before the system is set for production. One of the simplest and most useful techniques is to hold hardware and software validation and verification reviews. Validation design reviews of hardware and software should include the systems engineers who have the best understanding of the customer requirements. Verification hardware design and software code reviews, or peer reviews, are an excellent means of finding errors upstream in the development process. Managers may have to decide whether to allocate resources upstream, when the errors are easier to fix, or downstream, when the ramifications can be much more drastic. Consider the difference between a code review finding a problem in code, and having the author change it and recompile, versus finding a problem after the product has been sold and in the field, where an expensive product recall may be required.

Debuggers

Edsgar Dijkstra, a pioneer in the development of programming as a discipline, discouraged the terms “bug” and “debug,” and considered such terms harmful to the status of software engineering. They are, however, used commonly in the field. A debugger is a software program that allows a view of what is happening with the program code and data while the program is executing. Generally it runs on a PC that is connected to a special type of development microcontroller called an emulator. While debuggers can be quite useful in finding and correcting errors in code, they are not real-time, and so can actually create computer operating properly (COP) errors. However, if background debug mode (BDM) is available on the microprocessor, the debugger can be used to step through the algorithm of the program, making sure that the code is operating as expected. Intermediate and final variable values, especially those related to some analog input or output value, can be checked. Most debuggers allow multiple open windows, the setting of program execution break points in the code, and sometimes even the reflashing of the program into the microcontroller emulator. An example is the Noral debugger available for the Motorola HC12.

The software in the microcontroller can also check itself and its hardware. By programming in a checksum, or total, of designated portions of ROM and/or EEPROM, the software can check to make sure that program and data are correct. By alternately writing and reading 0x55 and 0xAA to RAM (the “checkerboard test”), the program can verify that RAM and the bus are operating properly. These startup tasks should be done with every product operation cycle.

Logic Analyzer

A logic analyzer is a device for nonintrusive monitoring and testing of the microcontroller. It is usually connected to both the microcontroller and a simulator. While the microcontroller is running its program and processing data, the simulator is simulating inputs and displaying outputs of the system. A “trigger word” can be entered into the logic analyzer. This is a bit pattern that will be on one of the buses monitored by the logic analyzer. With this trigger, the bus traffic around that point of interest can be captured and stored in the memory of the analyzer. An inverse assembler in the analyzer allows the machine code on the bus to be seen and analyzed in the form of the assembly level commands of the program. The analyzer can also capture the analog outputs of the microcontroller. This could be used to verify that the correct PWM duty cycle is being commanded. The simulator can introduce shorts or opens into the system, then the analyzer is used to see if the software correctly responds to the faults. The logic analyzer can also monitor the master loop of the system, making sure that the system completes all of its tasks within a designated time, e.g., 15 ms. An example of a logic analyzer is the Hewlett Packard HP54620.

3.10 Summary

This chapter introduced a number of topics regarding a mechatronic system. These topics included not just mechatronic input, output, and processing, but also design, development, and testing. Future chapters will cover all of this material in much greater detail.

4

Microprocessor-Based Controllers and Microelectronics

4.1 Introduction to Microelectronics

The field of microelectronics has changed dramatically during the last two decades and digital technology has governed most of the application fields in electronics. The design of digital systems is supported by thousands of different integrated circuits supplied by many manufacturers across the world. This makes both the design and the production of electronic products much easier and cost effective. The permanent growth of integrated circuit speed, scale of integration, and reduction of costs have resulted in digital circuits being used instead of classical analog solutions of controllers, filters, and (de)modulators.

The growth in computational power can be demonstrated with the following example. One single-chip microcontroller has the computational power equal to that of one 1992 vintage computer notebook. This single-chip microcontroller has the computational power equal to four 1981 vintage IBM personal computers, or to two 1972 vintage IBM 370 mainframe computers.

Digital integrated circuits are designed to be universal and are produced in large numbers. Modern integrated circuits have many upgraded features from earlier designs, which allow for “user-friendlier” access and control. As the parameters of Integrated circuits (ICs) influence not only the individually designed IC, but all the circuits that must cooperate with it, a roadmap of the future development of IC technology is updated every year. From this roadmap we can estimate future parameters of the ICs, and adapt our designs to future demands. The relative growth of the number of integrated transistors on a chip is relatively stable. In the case of memory elements, it is equal to approximately 1.5 times the current amount. In the case of other digital ICs, it is equal to approximately 1.35 times the current amount.

In digital electronics, we use quantities called logical values instead of the analog quantities of voltage and current. Logical variables usually correspond to the voltage of the signal, but they have only two values: log.1 and log.0. If a digital circuit processes a logical variable, a correct value is recognized because between the logical value voltages there is a gap (see Fig. 4.1). We can arbitrarily improve the resolution of signals by simply using more bits.

4.2 Digital Logic

Digital circuits are composed of logic gates, such as elementary electronic circuits operating in only two states. These gates operate in such a way that the resulting logical value corresponds to the resulting value of the Boolean algebra statements. This means that with the help of gates we can realize every logical and arithmetical operation. These operations are performed in combinational circuits for which the resulting value is dependent only on the actual state of the inputs variables. Of course, logic gates are not enough for automata construction. For creating an automaton, we also need some memory elements in which we capture the responses of the arithmetical and logical blocks.

A typical scheme of a digital finite state automaton is given in Fig. 4.2. The automata can be constructed from standard ICs containing logic gates, more complex combinational logic blocks and registers, counters, memories, and other standard sequential ICs assembled on a printed circuit board. Another possibility is to use application specific integrated circuits (ASIC), either programmable or full custom, for a more advanced design. This approach is suitable for designs where fast hardware solutions are preferred. Another possibility is to use microcontrollers that are designed to serve as universal automata, which function can be specified by memory programming.

4.3 Overview of Control Computers

Huge, complex, and power-consuming single-room mainframe computers and, later, single-case mini-computers were primarily used for scientific and technical computing (e.g., in FORTRAN, ALGOL) and for database applications (e.g., in COBOL). The invention in 1971 of a universal central processing unit (CPU) in a single chip microprocessor caused a revolution in the computer technology. Beginning in

1981, multi-boxes (desktop or tower case, monitor, keyboard, mouse) or single-box (notebook) micro-computers became a daily-used personal tool for word processing, spreadsheet calculation, game playing, drawing, multimedia processing, and presentations. When connected in a local area network (LAN) or over the Internet, these “personal computers (PCs)” are able to exchange data and to browse the World Wide Web (WWW).

Besides these “visible” computers, many embedded microcomputers are hidden in products such as machines, vehicles, measuring instruments, telecommunication devices, home appliances, consumer electronic products (cameras, hi-fi systems, televisions, video recorders, mobile phones, music instru-ments, toys, air-conditioning). They are connected with sensors, user interfaces (buttons and displays), and actuators. Programmability of such controllers brings flexibility to the devices (function program choice), some kind of intelligence (fuzzy logic), and user-friendly action. It ensures higher reliability and easier maintenance, repairs, (auto)calibration, (auto)diagnostics, and introduces the possibility of their interconnection—mutual communication or hierarchical control in a whole plant or in a smart house. A photograph of an electrically operated instrument is given in Fig. 4.3.

Embedded microcomputers are based on the Harvard architecture where code and data memories are split. Firmware (program code) is cross-compiled on a development system and then resides in a non-volatile memory. In this way, a single main program can run immediately after a supply is switched on. Relatively expensive and shock sensitive mechanical memory devices (hard disks) and vacuum tube monitors have been replaced with memory cards or solid state disks (if an archive memory is essential) and LED segment displays or LCDs. A PC-like keyboard can be replaced by a device/function specifically labeled key set and/or common keys (arrows, Enter, Escape) completed with numeric keys, if necessary. Such key sets, auxiliary switches, large buttons, the main switch, and display can be located in water and dust resistant operator panels.

Progress in circuit integration caused fast development of microcontrollers in the last two decades. Code memory, data memory, clock generator, and a diverse set of peripheral circuits are integrated with the CPU (Fig. 4.4) to insert such complete single-chip microcomputers into an application specific PCB.

Digital signal processors (DSPs) are specialized embedded microprocessors with some on-chip periph-erals but with external ADC/DAC, which represent the most important input/output channel. DSPs have a parallel computing architecture and a fixed point or floating point instruction set optimized for typical signal processing operations such as discrete transformations, filtering, convolution, and coding. We can find DSPs in applications like sound processing/generation, sensor (e.g., vibration) signal analysis, telecommunications (e.g., bandpass filter and digital modulation/demodulation in mobile phones, com-munication transceivers, modems), and vector control of AC motors.

Mass production (i.e., low cost), wide-spread knowledge of operation, comprehensive access to soft-ware development and debugging tools, and millions of ready-to-use code lines make PCs useful for computing-intensive measurement and control applications, although their architecture and operating systems are not well suited for this purpose.

As a result of computer expansion, there exists a broad spectrum of computing/processing means from powerful workstations, top-end PCs and VXI systems (64/32 bits, over 1000 MFLOPS/MIPS, 1000 MB of memory, input power over 100 W, cost about $10,000), downwards to PC-based computer cards/modules (32 bits, 100–300 MFLOPS/MIPS, 10–100 MB, cost less than $1000). Microprocessor cards/modules (16/8 bits, 10–30 MIPS, 1 MB, cost about $100), complex microcontroller chips (16/8 bits, 10–30 MIPS, 10–100 KB, cost about $10), and simple 8-pin microcontrollers (8 bits, 1–5 MIPS, 1 KB, 10 mW, cost about $1) are also available for very little money.