We have divided the model of a system to be developed into two stages, the essential model described in Volume 2, and the implementation model described in this volume. The division introduces overhead into the modeling process, since the entire content of the essential model must be reorganized and incorporated into the implementation model before addition of details of the implementation technology. Although the overhead of building the model in stages can be reduced by the use of automated support tools for the modeling process, it cannot be eliminated. There is thus a very understandable tendency on the part of systems development teams to eliminate the overhead by building a single-stage system model incorporating both the underlying logic and the implementation details. However, our experience with a large number of development projects indicates that the single-model approach can cause problems, due largely to the necessary involvement of both end-users and automated systems specialists in the development process.

These two groups tend to differ substantially in their perspective on systems development. In the business systems environment, the difference between users and computer specialists is often attributed to the users’ lack of technical sophistication. However, this is clearly not the case in the science/engineering arena, where the average end-user (defined as the technical manager, scientist, or engineer responsible for the area within which an embedded system operates) is technically quite sophisticated and probably understands at least the fundamentals of computer technology. The difference in perspective is fundamentally due not to technical sophistication but to different perceptions of the subject matter of embedded systems. The chemical engineer, for example, sees a process control system principally in terms of monitoring and control of reaction variables, optimization of yield, and so on — in other words, in chemical terms. The software engineer sees a process control system principally in terms of operation of concurrent tasks, resolution of priority conflicts, and so on — in other words, in computer terms. Obviously, the software engineer must be aware of the chemical engineering logic and data structures incorporated into the system. However, the logic and data structures are in a sense “raw materials” to be manipulated by the implementation technology. Similarly, the chemical engineer must be comfortable with aspects of computer technology such as system-user interfaces, but will see them mainly as transportation conduits for chemical data.

The systems modeling process, to be successful, must inherently incorporate quality assurance — in other words, both end-users and software engineers must “sign off” on some version of the system model. We are convinced that a single-stage model cannot satisfy the differing needs of end-users and software engineers to understand a proposed system in their own terms. Therefore, the essential-implementation model distinction is a fundamental heuristic, a necessary part of the “style” of applying formal modeling tools to the development process. We urge the systems developers using our approach to try the two model stages, at least on a pilot basis, and to evaluate the results, rather than opting prematurely for a single model.