Simulation Engineering: Build Better Embedded Systems Faster by Jim Ledin

From the Publisher

Simulation Engineering describes the methods of dynamic system simulation from the ground up. Important techniques are presented, beginning with the fundamentals of mathematical models — how to produce useful results, how to analyze and visualize data, and how to verify and validate models. In addition to step-by-step instructions for developing working simulations, the author discusses determining when simulation is appropriate, managing the cost of simulation, and communicating results. The final chapter provides an overview of current tools available for model development, digital simulation, and HIL simulation, such as ARTS, ADI Simsystem, and Matlab/Simulink.

Product Details

• Table of Contents
• Forewords & Introductions
• Read an Excerpt

Table of Contents

Forewords & Introductions

Preface

The intent of this book is twofold. First, it providesn introduction and background to dynamic system simulation that covers both of the meanings discussed above. Second, it contains practical techniques and approaches that have been used successfully in the development and test processes for different types of complex embedded systems over many years. This book is intended for use by engineers, managers, and others involved in the development and test processes for embedded systems, as well as by students and anyone else with an interest in dynamic system simulation.

I would like to gratefully acknowledge the assistance provided by Dr. Jack Crenshaw in his incisive technical review of this material. I would also like to thank the staff at CMP Books for their support in this effort. Finally, I want to thank my lovely wife, Lynda, for the patience, encouragement, and help she has provided during the writing of this book.

Read an Excerpt

Simulation Engineering

1.1 Introduction

Simulation is an approach that can significantly accelerate the product development cycle and provide higher quality in the final system. A simulation contains a set of mathematical models of one or more dynamic systems and the interactions between those systems and their environment. During execution, the simulation advances through time and solves the equations for all the models at each point in time. The equations that describe the behavior of complex systems are complex themselves - so the approach used in simulation is often the only way to solve them with an acceptable degree of accuracy. Simulation can play several roles during the development of a dynamic embedded system. It is useful for

• exploring design options,
• optimizing design parameters,
• as a tool for thoroughly testing the system under realistic conditions, and
• other applications such as failure analysis.

It is critically important that a simulation accurately reflect the behavior of the system and environment being simulated. It is crucial that each model in the simulation - as well as the complete simulation application itself - undergo a thorough procedure to demonstrate its accuracy. Chapter 7 is devoted to a discussion of simulation verification, validation, and accreditation, which are the processes used to demonstrate the degree to which each mathematical model (and the full simulation) are sufficiently correct and accurate for their intended uses.

Because simulation development and execution is commonly performed using an off-the-shelf simulation software package, Chapter 9 describes several current simulation tools and demonstrates the implementation of a simple yet nontrivial system simulation in each one. Demonstration versions of each of these packages, as well as others that are not discussed in this book, are generally available from vendors at no cost for a limited period. Developers considering which tool to buy should try out several and select the one that best meets their needs.

Before diving into the issues of modeling and simulating dynamic systems, it's important to discuss reasons why it is needed and identify some of tae benefits that accrue from the use of simulation.

1.2 Embedded Systems

However, low-cost computing hardware is only one part of an embedded system. Before this hardware can do anything at all, someone must develop software to run on it. Embedded software must undergo a design, development, and testing process similar in many ways to

2. Gordon E. Moore, co-founder of Intel, made the observation in 1965 that the number of transistors per square inch on integrated circuits had doubled approximately every year since the integrated circuit was invented. In subsequent years, the pace slowed somewhat so that the current rate of transistor doubling is about every 18 months.

the hardware development process. As the complexity of the tasks performed by the software in an embedded system increases, so does the time and expense required for the development process. In many cases, the software development costs for an embedded project exceed the costs for hardware development, sometimes by a substantial amount [1]. Because of the large and growing percentage of product development resources expended on software, techniques for improving the software development process are becoming increasingly important.

In addition to the hardware and software development costs of a complex embedded product, hardware/software integration can also be a source of significant expense and risk. Often the hardware and software development efforts occur in parallel. This means that the software developers cannot run their code on the actual embedded hardware until a prototype becomes available, which may not occur until after completion of the bulk of the software development. As anyone who has worked on a sizable software project knows, debugging a large, untested chunk of software is vastly more difficult than developing and debugging it a little bit at a time. Projects can become bogged down in problems during the hardware/software integration phase, frequently leading to lengthy delays, exploding costs, and outright project failure. There is a critical need for techniques that can reduce the risks associated with parallel hardware and software development. Simulation is one way to reduce these risks.

Users will continue to demand more product capabilities causing developers of competing products to strive to provide solutions that meet those needs. To flourish in this environment, companies must adapt themselves and their processes to the realities dictated by complex dynamic embedded systems. These large software projects will require the use of the best available development and test methodologies to a) minimize the number of software problems that occur in fielded systems, and b) to minimize the negative effects of those problems should they appear. Simulation is a useful tool for meeting these goals.

Software problems can arise from many sources, for example

• incorrect algorithm implementation,
• accessing hardware devices improperly,
• and failing to handle exceptional conditions (e.g., division by zero) properly.

An example of a software requirements-related system problem occurred in the Patriot missile system used in the Gulf War. On February 25, 1991, a Patriot missile battery in Saudi Arabia was unable to engage an incoming Scud missile due to an excessive amount of clock drift in its target tracking system. The Scud subsequently struck a warehouse in Dhahran and killed 28 U.S. soldiers. An investigation determined that the real-time clock in the Patriot targeting system steadily drifted away from the correct time due to rounding error [2]. When the system had been running continuously for a long time (over 100 hours, in the case of the failure), sufficient clock error would accumulate so that the system could not acquire a target.

After this failure, the system developers produced a software patch that fixed the clock drift problem. This led to the popular belief that the root cause of the problem was a software error. However, the problem may not have just been a slowly drifting real-time clock. The original requirements for the Patriot system apparently did not envision that the missile batteries would remain in a continuously operational state for more than a few hours at a time. During the Gulf War, Patriot missile batteries often remained in the operational state for several days at a time. This allowed the clock error to grow to the point that the targeting system would not function. The conclusion in this affair appears to be that the system met its original requirements (even with the clock drift present), but in the operational situation, it was used in a manner that was not compatible with those requirements. This resulted in the complete failure of the system to perform its intended task.

The root problem in this case may have been a combination of a limitation in the original system requirements and improper operation by the end users (possibly due to inadequate user training or poor system documentation). It does not appear to have been a problem of software design or implementation, because all real systems are specified in terms of error tolerances. The developer must meet those tolerances, but it is not appropriate to expend resources in an attempt to further minimize errors once the tolerances are satisfied. If the system meets the specifications but still does not function correctly, the specified tolerances may not be tight enough.

Software development practices and tools are steadily evolving to increase the efficiency and quality of the development process, but there are no breakthroughs on the horizon that would dramatically improve the situation. Incremental enhancements will occur as software tools become available that improve some aspects of the software development and test processes. Better developer and management practices will improve their ability to meet project goals. Even with the use of refined tools and practices, however, the development and testing of software is likely to remain a slow, labor-intensive process for years to come.

Software development and test complexity, hardware/software integration, and requirements analysis can be major problems in the development of complex dynamic embedded systems. Cost-effective approaches must be developed and implemented to deal with these issues in ways that reduce the risk of encountering expensive and difficult-to-fix system errors during development and particularly after development is completed. The earlier in the cycle that meaningful system-level testing can be performed, the easier and less risky final system integration will be. Any approach that allows earlier testing of embedded software can improve the chances for a successful, on-time, on-budget development effort. As you will see, simulation is a technique that meets this need.

7.3 Simulation

• Circuit simulation (Will the circuit meet timing requirements?)
• Thermal simulation (Will any of the chips on the board get too hot?)
• Network simulation (Will congestion be a problem?)

We can test hardware and software at the subsystem level using hardware-in-the-loop (HIL) simulations long before a testable system prototype becomes available. HIL simulations run at real-time speeds and perform input/output operations with the system or subsystem so that the test item "thinks" it is operating as part of a real system in its operational environment. These systems or subsystems can then be tested under nominal conditions as well as beyond their intended operational boundaries. HIL simulation provides the ability to thoroughly test subsystems early in the development process. This can greatly reduce the debugging time and project risk compared to the alternative approach of waiting until a prototype is completed before performing integration and testing.

Many important ancillary issues must be addressed to gain the full set of potential benefits from a simulation effort. Two examples of these areas are simulation verification and validation. Verification is the process used to demonstrate that a simulation has been implemented according to its specifications. The validation process demonstrates that the simulation is a sufficiently good representation of the actual system it attempts to simulate. The primary goal of the verification and validation processes is to provide sufficient, convincing evidence of the correctness of the simulation so that even the most sceptical observers will agree that it is credible and accurate for its intended purposes.

Another issue involves the methods used to effectively analyze and process the large amounts of output data generated by a simulation. There must be adequate tools and techniques available for extracting useful information from all of the output data. Some of the data will need to be archived for later use for such purposes as regression testing (which verifies that the simulation continues to work correctly after undergoing significant modifications).

1.4 Complex Products