Because Soar and ModSAF are undergoing continued independent development, the SMI is designed in a modular fashion to allow new versions of ModSAF and Soar to be easily incorporated. The Soar system is already implemented with a number of hook functions and configurable subsystems such as its command interpreter. Some of these facilities were generalized to work more effectively with external systems such as ModSAF, but no changes were needed to the Soar system releases. All SMI functionality is incorporated through Soar's extensible mechanisms. The SMI redefines Soar's scheduling command since ModSAF is in charge of scheduling, and adds a number of commands useful in the air combat domain. The SMI also adds a set of domain-specific right-hand side functions used in Soar productions.
ModSAF is also designed with modularity as an important goal. Hence, only one library out of over 100 was modified to incorporate Soar and the SMI. In this library, the SMI is implemented as a software layer connected to ModSAF at a level dealing with the aircraft vehicle simulation. The SMI calls upon a number of ModSAF libraries to help create a simulated cockpit. The ModSAF main program and a few additional libraries required minor additions to accomodate the SMI but their primary functionality was not altered.
The higher-level tasks of ModSAF are not used since a Soar agent typically deliberates about such things. The separation of vehicle simulation and tasks in ModSAF is not perfect, so the SMI fills in the gaps to provide a cockpit simulation to Soar agents. This means that some of the functionality provided in tasks must be recreated in the SMI. This is due to the fact that there is no convenient way to use the functionality of the tasks without committing to use of more ModSAF machinery.
The incorporation of Soar, ModSAF, and the SMI into one process was fairly easy since all are written in the C language and utilize user-defined C libraries. The communication overhead is reduced by handling all I/O data flow through C function calls. To ease the task of adding Soar input working memory elements, an existing package was used that provides a convenient API to manage input working memory element retractions and assertions [Scott Huffmans's SoarSim reference].