CAD for Control Systems

Derek A. Linkens

• Publisher: CRC Press
• Year: 2020
• ISBN:
  9781000148886
• Edition: 1
• Topic: Computer Science
• Subtopic: CAD-CAM
• Index: Computer Science

This comprehensive collection brings together current information on CAD for control systems including present and future trends in computer-aided design exploring the areas of modeling, simulation, simulation languages, environments, and design techniques. Presenting a systems approach to control d

1

Integrated Continuous-System Modeling and Simulation Environments

François E. Cellier

University of Arizona
Tucson, Arizona

1.1 INTRODUCTION

The field of simulation software was last reviewed by me in 1983 [7]. A lot has happened since 1983. At that time, most continuous-system simulations were still performed on either CDC or IBM mainframes. Many engineers still wrote their simulation software in Fortran because the simulation languages of that era were not available at the site (mainframe software tended to be quite expensive), or not implemented on the particular hardware platform, or too slow for the intended purpose, or too restricted in their modeling capabilities.

Today’s Engineering Workstations place more number-crunching power and a larger memory allocation on the average engineer’s personal desk than the mainframes of one decade ago had to offer to an entire enterprise. We have seen a trend toward standardization of operating system software across different hardware vendors with, since the design of the RISC architectures, a strong trend toward accepting UNIX as the “universal” operating system language, and C as the “universal” programming language. We have seen standardization of graphics software with X-Windows becoming the de facto standard of low-level graphics, and Open Look and Motif the (unfortunately still two) de facto standards of higher-level graphic functions. We have seen a standardization of the ASCII representation of graphics in the form of the Postscript language, which, for the first time, allows engineers and scientists to make their papers (including figures) available electronically to their colleagues around the globe by placing them in so-called “anonymous FTP” accounts. We have finally seen the general acceptance of the object-oriented (OO) programming paradigm as a means of managing large pieces of code in a modular fashion with C+ + emerging as the most widely used OO programming language.

One decade ago, the operating system kernels offered on mainframes were extremely rudimentary. This was a deliberate choice since computer manufacturers wanted to make a large percentage of the scarce computer cycles and memory cells available to the end user, keeping the overhead of the operating software (both in terms of CPU cycles and occupied memory) as small as they could get away with. Today’s trend is just the opposite. The operating system software is made as comfortable to use as possible, irrespective of how much resources the operating system consumes. The time of the engineer is a considerably more precious and scarcer commodity than either CPU cycles or memory chips. After all, the Engineering Workstation is idling most of the time, waiting for its slow single interactive user to issue the next command.

For this reason, the implementation of flexible integrated software environments was unthinkable at the time when my last survey was written. To be more precise, the first integrated simulation environment, TESS [39], was in its early design phase [38] around the time when my last review was written. However, the first version of TESS, released in 1985, offered a rather crude environment (operating) language, rudimentary graphics only, a painfully slow and not very robust database, and was generally a far cry from what can be achieved today. TESS deserves credit though for being visionary in predicting what simulation-ists would ask for in terms of simulation support software in the years to come.

In light of the rapid development of computer technology over the past decade, I was delighted when I was asked to undertake a new effort of surveying the state-of-the-art of continuous-system simulation software. However, whereas my previous review focused on features and capabilities of individual simulation languages, the current review places its emphasis on integrated modeling and simulation software environments, stating what has been achieved so far, and daring to predict what the near future might bring in addition.

1.2 SIMULATION SOFTWARE

Many of the simulation languages that were reviewed in 1983 are still in use. If anything, they have become more popular than ever. ACSL [31] is still the most widely used continuous-system simulation language on the market, and for good reasons. It provides flexible model specification capabilities, excellent integration algorithms, and both the ACSL preprocessor and the ACSL run-time system are satisfyingly robust.

One of the major reasons why I did not and could not use ACSL in my research projects at the time of my last review was ACSL’s lack of capabilities to handle discontinuities properly [6]. However, shortly after my last review, the schedule statement was introduced into ACSL, which now allows one to handle discontinuous models adequately. This feature is still not implemented in an optimal fashion because many of the built-in discontinuous functions (such as the step function) have not been recoded to make use of the new facility, but this does not prevent me from using ACSL; it only prevents me from using those built-in functions.

At the time of my last review, ACSL had been fairly new on the market and its preprocessor still contained an unhealthy number of bugs. However, Mitchell & Gauthier offer excellent software support. When I report a problem to them, I usually obtain a fix within 24 to 72 hours. In the mean time, ACSL has matured tremendously. Its preprocessor is now mostly bug-free. Over the past 2 years, I discovered only one new true bug in the ACSL compiler, which was related to a table overflow with handling an unearthly large model (ACSL provided for 10,000 generic variable names, whereas my program needed more). As usual, I received a bug fix within less than a day.

One decade ago, the interface between ACSL’s run-time software and its integration algorithms, particularly the Gear algorithm, still had a few problems. However, in the meantime these have been fixed, and I have not discovered any new integration problems with ACSL in a long time.

The availability of ultrafast Engineering Workstations (45 Mips or more) makes it now feasible to apply ACSL even to very large and numerically difficult problems such as the solution of two-dimensional parabolic partial differential equations discretized using the method-of-lines approach.

The initial versio...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Preface
• Table of Contents
• Contributors
• Part I. Modeling and Identification
• Part II. Simulation Languages
• Part III. Design Techniques and Tools
• Part IV. CAD Environments and HCI
• Index