Choosing Discrete-Event Simulation Software

The software package must have undergone rigid verification and validation, and the vendor should provide certification to that effect.

The software should include tasks robust enough to satisfy a wide range of events and operations, including queues, first-in/first-out or last-in/first-out lists, broadcast, signals, wait/delay/go, and randomness.

The software should contain a suite of report functions, statistical analysis functions, and graphical output/displays, including hard-copy and electronic versions.

The software should have sufficient throughput to accomplish end-to-end simulations in reasonable, if not real, time. Such simulations may include the assembly process of the manufacturing group; the device's hardware and software, and their interfaces; or the user interface of a device that accounts for key presses, debounce time, hardware response time, and software recognition and interpretation.

The software should interface with other external software packages. For example, it should produce data files or link to LabView (National Instruments, Austin, TX), test tools, and automated test suites such as Validor and Validor Gold (B-Tree Systems, Minneapolis). In addition, the simulator should be able to link to, call, or interface with software developed by the user.

The software should provide enough flexibility to be able to model patients and their physical attributes. For example, it should model blood pressure, body temperature, respiration, flows, blood chemistry, fluids, height, weight, and reach. This would be useful for modeling a patient using the device and a health-care provider operating the device.

Last and most important, the software must quantify time from hours to fractions of a second—the latter is particularly useful for simulating end-to-end processes.