When can we safely reuse systems,
upgrade systems or
use COTS components?

Terry Bahill
Systems and Industrial Engineering
University of Arizona
Tucson, AZ 85721-0020, USA
terry@sie.arizona.edu
http://www.sie.arizona.edu/sysengr/slides/homophone.ppt
© 2000-2004 Bahill

Reusability, upgrades and pressure to use commercial off the shelf (COTS) systems force the question "How can we prove that two systems are equivalent?" First, suppose a system called Z1 was designed to perform task-1. Next, suppose task-2 needs to be performed. A new system called Z2 could be designed, or perhaps Z1 could be reused. In many cases, it would be a lot cheaper to reuse Z1. For simplicity assume task-2 is a subset of task-1, for example task-1 could be spelling and grammar checking and task-2 might be only spelling checking. A necessary, but not sufficient, condition for using Z1 for task-2 is that the I/O behavior of Z1 and Z2 be identical for task-2. For example, the I/O behavior of Z1 and Z2 would have to be identical when checking spelling. Second, suppose that we have a large complex system that has been working well for several years. But the hardware is getting old and expensive to maintain. Will our application still work if we upgrade from hardware-1 to hardware-2? Or perhaps our software vendor has come out with a new version. Other sites have upgraded, but we have not, so we are losing compatibility. Will our application still work if we upgrade from software-1 to software-2? A necessary but not sufficient condition for success of the upgrade is that the input/output behavior of the application be the same on the old system as it is on the new system. Third, suppose we make custom systems for our customer. They work very well, but they are expensive. Now our customer wants us to design a new system, but to keep the cost down, he wants us to use commercial off the shelf (COTS) components. We have a design, Z1, that satisfies the customer's needed functionality. But we want to know if a COTS product, Z2, will also satisfy this functionality. For a start, we can create input trajectories, play them into both designs and look to see if the output trajectories are the same. These three scenarios require answers to the same question as our old systems engineering validation problem. Suppose Engineering designs a system, then Manufacturing builds a physical system. Could an engineer prove that the physical system implements the design? If the states were observable, then the engineer could construct an input trajectory that exercised all state transitions, apply this input trajectory to both systems and compare the resulting state trajectories. If they were identical, then the systems would be equivalent. However, if the system states were not observable, then the only thing the engineer could work with is the input/output behavior of the systems. In this paper, we show what you can say about systems where only the inputs and outputs can be observed.

References [76]. This is a systems theory lecture. It is suitable for engineers. This talk requires an overhead projector (or PowerPoint and a computer projection system). This talk takes one hour.