- A History of Increasing Complexity
- Mechatronic System Organization
- Amplifiers and Isolation
- Scope: The Unit Machine
- Control
- Real-Time Software
- Nasty Software Properties
- Engineering Design and Computational Performance
- Control System Organization
- Software Portability
- Operator Interface
- Multicomputer Systems: Communication
- The Design and Implementation Process
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.6 Real-Time Software
The dominant implementation medium as well as primary medium of expression for contemporary mechatronic systems is real-time software. Real-time software is a subdomain of software generally with distinct requirements and characteristics. While implementation media are subject to change, software is so dominant now that any design methodologies that are used must allow for the effective implementation of control systems using real-time software.
Real-time software differs from conventional software in that its results must not only be numerically and logically correct, they must also be delivered at the correct time. A design corollary following from this definition is that real-time software must embody the concept of duration, which is not part of conventional software. Duration is such an important concept that it will be the focus of the documentation technique used as the heart of a design methodology for producing reliable control system software.
Two terms in common use in this field have overlapping, but not identical meanings. These are real time, as used here, and embedded. Embedded refers to computers that are parts of other items and are not explicitly visible to the user. For example, a mobile (cell) phone has one or more embedded computers in it. These computers control the user interaction via the keyboard and display, control the connection between the phone and its nearest base station, filter the incoming signals to remove noise, encrypt and decrypt messages for security purposes, and so on. On the other hand, a pocket size personal digital assistant (PDA) is a computer. Even though the computer in it is of roughly the same capability and performs many of the same functions as the computer in the mobile phone, it is not thought of as embedded. Embedded computers may—or may not—perform functions that require real-time software. The functions they perform may or may not have time critical components. Real-time software, however, can run on embedded computers or on computers which are doing control functions but are clearly free-standing and not built into the target system.
Thus, many, but not most, embedded computers run real-time software, and many, but not most, real-time software runs on embedded computers.
An example showing the need for on-time delivery of results is the masterless cam grinder shown in figure 1-5. In the masterless cam grinder, the cam which is being ground to shape is rotated while the linear positioner moves back and forth to generate the desired shape for the cam. The rotation of the cam must be precisely coordinated with transverse motion to cut the noncircular cam profile.
)
Figure 1-5. Masterless cam grinder
This is an example of how mechatronics can change the way that problems are approached. In a conventional, mastered cam grinder the motion is controlled by a mechanical system which traces the contour of a master cam. The mechanical tracing mechanism must fill the role of computation (transmission of the desired contour) but also carry enough power to operate the mechanism. This is a limit to performance and can cause a considerable loss of productivity since the time to change the machine from one cam profile to another is considerable. Performance limitations come about because of the dynamics associated with the accelerations of the elements of the mechanism carrying the information from the master to the blank cam, because of friction in that mechanism, and because of other real-world effects. The result is that for high-precision cams, such as those used for automotive engines, the master usually has to be made slightly differently than the actual desired shape of the final product to compensate for these changes. Ironically, given the automotive application, the question may be asked: Why use a cam at all to manipulate the engine valves? In fact, there has been considerable work on electrically actuated valves, but they have not yet been used on mainline production automobiles.
In the mechatronics-based cam grinder, the profile is stored in an array of numbers in software, so the machine's performance is limited only by its inherent mechanical properties. Changing the machinery to make a different cam profile is also much faster since it only requires the loading of new data instead of the installation of new mechanical hardware in the form of the master cam.
The real-time software used in most mechanical system control is also safety critical. Software malfunctions can result in serious injury and/or significant property damage. In discussing a series of software-related accidents which resulted in deaths and serious injuries from clinical use of a radiation therapy machine called the Therac-25, Leveson and Turner established a set of software design principles ". . . that apparently were violated with the Therac-25. . . " These principles are:
Documentation should not be an afterthought.
Software quality assurance practices and standards should be established.
Designs should be kept simple.
Ways to get information about errors—for example, software audit trails—should be designed into the software from the beginning.
The software should be subjected to extensive testing and formal analysis at the module and software level; system testing alone is not adequate.
In particular, it was determined that a number of these problems were associated with asynchronous operations which, while uncommon in conventional software, are the heart and soul of real-time software. Asynchronous operations arise from the interaction of the software with the physical system under control. In most cases, the physical system is made up of many components, all operating simultaneously. Although the function of the software is to coordinate this operation, events occurring at nearly the same time in the physical system do not necessarily have a predictable order. Thus, operation of the system may change from one cycle to another if the order of one or more of these events changes. The software must be designed in such a way that it operates correctly despite this lack of detailed predictability. Note that if the order of events is important to correct system operation, the control software must assure the correct order. However, there are many events that occur at nearly the same time for which order is not important.
Because of asynchronous operation, it becomes impossible to predict when groups of program statements will execute relative to other groups, as it is in synchronous software. Errors that depend on a particular execution order will only show up on a statistical basis, not predictably. Thus, the technique of repeating execution until the source of an error is found, which is so effective for synchronous (conventional) software, will not work for this class of real-time error.
In a like manner, there are errors that depend on the coincidence of certain sections of program code and events taking place in the physical system. Again, because these systems are not strictly synchronized, they can only have statistical characterization.