Model-Integrated System Development:Models, Architecture, and Process

Gabor Karsai, Amit Misra, Janos Sztipanovits, Akos Ledeczi, Michael MooreDepartment of Electrical and Computer Engineering

Vanderbilt UniversityNashville, TN 37235 USA�

gabor,misra,sztipaj,akos,msm� @vuse.vanderbilt.edu

Abstract

Many large software systems are tightly integrated withtheir physical environments and must be adapted whentheir environment changes. Typically, software developmentmethodologies do not place a great emphasis on modelingthe system’s environment, and hence environmental changesmay lead to significant and complicated changes in the soft-ware. In this paper we argue that (1) the modeling of theenvironment should be an integral part of the process, and(2) to support software evolution, wherever possible, thesoftware should be automatically generated. We presenta model-integrated development approach that is capableof supporting cost effective system evolution in accordancewith changes in the system’s environment. The approach issupported by a “meta-architecture” that provides a frame-work for building model-based systems. This frameworkhas been successfully used in various projects. One of theseprojects, a site-production flow visualization system for alarge manufacturing operation, is analyzed in detail.

1. Introduction

Every software practitioner knows the difficulties ofmaintaining a large software system that is tightly coupledto a physical environment which is periodically undergo-ing configuration changes. In fact, it is probable that thesesystems are rather the rule than the exception.

Naturally, there are a lot of causes for this problem, butthere seem to exist some aspects that are more prevalentthan others. Let us look at an example system that monitorsand controls a large-scale manufacturing operation. Thesystem collects data from thousands of sources (PLC-s, mi-croswitches, etc.), archives the data values, makes the data

available to operators and managers (after processing), andis also involved in making automatic decisions enforcingsome level of production control. It is a fact of businessthat the plant changes and evolves necessitating changesand upgrades in the software system. One has to change thedatabase schema, recompile applications, reconfigure dataacquisition systems, etc. just to maintain existing function-alities. These many-faceted activities involve diverse soft-ware engineering issues, and the maintenance of the systembecomes a highly non-trivial activity. It is interesting tonote, that software engineers must become plant engineers(up to a certain degree, of course) in order to understandhow the plant works. While it is important from a businesspoint of view for the software engineers to become familiarwith the problem domain, this results in a duplication ofeffort, since the plant engineers are already experts in theirdomain. Furthermore, it seems that the software configu-ration changes should be closely coupled to configurationchanges in the plant, i.e. the environment of the software.

In this paper, we advocate an approach that addresses thisproblem. First we describe the approach on an abstract level,then we present a set of tools that support the approach. Themajor part of the paper describes the process the we followedto develop an actual application for a large-scale manufac-turing operation. We discuss our experience with the processand give an objective evaluation of the work. Finally, werelate to other development approaches and conclude withshowing some future aspects of the development process.

2. Model-Integrated Development

Recognizing the need for software systems that evolveand are maintained in accordance with their environment,we propose the extensive use of models in the developmentprocess. The use of models in software development is not

Tools and components:

System Development Process:

Model Builder

Model Interpreter

Run-time Support

Creates

Creates

Creates

Define Modeling Paradigm

Develop Model Builder(s)

Develop Model Interpreter

Develop R-T Support

Executable

System

Models

Builds

Use

Use

Execute System

Build System

(Automatically)

Edit Models

End-User’s Process:

Figure 1. Model-Integrated System Develop-ment Process

a new idea. Various analysis and design techniques (espe-cially the object-oriented ones) build models of the systembefore implementation, and model its environment as well.However, we propose to extend and specialize the modelingprocess, so the models can be more tightly integrated intothe system development cycle than with traditional tech-niques. The process supporting this activity can be calledModel-Integrated Development (MID), and it results in amodel-integrated system (MIS).

In an MID process, the models play many central andessential roles, including:

� they describe the system’s environment,

� they represent the system’s architecture, and

� they are used in generating and configuring the system.

These models are indeed integrated with the system, in thesense that they are active participants in the developmentprocess, as opposed to being mere passive documents.

When MID is used in developing a system, models areinvolved in all stages of the life-cycle. To support this,the initial step is the building of tools that support modelcreation and editing. These model editing tools can later beused by the end-users when they want to customize the finalapplication. The model editing tools are typically graphical,but more importantly, they support modeling in terms of theactual application domain. This domain-specific modelingis essential for making end-user programmability feasible.The result of the model editing is a set of domain-specificmodels, that are typically kept in a database.

In order to use the models effectively, one needs (at least)two more components beyond model editors: (1) tools fortransforming abstract models into an executable system,and (2) run-time support libraries for the executable sys-tem. The transformation is done by a component called the

model interpreter. A model interpreter traverses the modeldatabase, analyzes the models, and “creates” the executablesystem. Model interpreters can be implemented using vari-ous strategies, depending on what the run-time system lookslike. For instance, if the run-time system includes a rela-tional database, model interpreters can generate the SQLdefinitions for the schema; if it is a multi-tasking kernel,model interpreters generate the code skeletons performingsynchronization; if it is a Petri-net simulator, they generatethe configuration tables for it. In the most general terms:the model interpreters are responsible for mapping domain-specific models into run-time components. Typically, run-time systems contain “generic” components that are special-ized according to need (as derived from the models). Theyform the run-time support libraries mentioned above. Notethat model interpreters perform an automatic system gen-eration by instantiating and customizing the generic com-ponents. The key in the process is that the models aredomain-specific, and do not (necessarily) include softwareconcepts.

At the process level, in MID, we have two interrelatedprocesses: (1) the process that involves the development ofthe model-integrated system, and (2) the process that is per-formed by the end-user of the system, in order to maintain,upgrade, and reconfigure the system, in accordance with thechanges in its environment. Figure 1 shows the processesschematically. The first process is performed entirely by thesystem’s developers (i.e. software engineers), the secondone is done initially by them, but later by the end-users.

To summarize, with MID the system is created throughthe following steps: (1) definition of a modeling paradigm,(2) development of the model builder (editor) environment,(3) development of the model interpreters, (4) developmentof the run-time support system. The product of this processis a set of tools: the model builder, model interpreter(s)and generic run-time support system. Using these, first thedevelopers, but eventually the end-users can build up theapplication itself by going through the following steps: (1)develop models, (2) interpret the models and automaticallygenerate the system, and (3) execute the system. The keyaspect of the development process is that domain-specificmodels are used in building the application, thus it can bere-generated by the end-users.

The MID approach can be contrasted with current devel-opment practices as follows. As opposed to developing ahighly specialized product, in MID we want to understandan entire class of problems related to the domain. As op-posed to developing a specific application, we try to developfirst the domain-specific tools to build that application, thenuse them (or have them used by the end-users) to generatethe application. Many of these ideas can already be found inother large-scale packages [2]. What is different here is that,in addition to making the models themselves available for

Figure 2. MGA Components

the end-users, we want to make explicit use of the modelsin generating applications.

It seems that MID necessitates a bigger effort thanstraightforward application development. This is true onlyif there is no reuse and every project has to start from scratch.In recent years we have developed a toolset called theMultigraph Architecture(MGA)[10] that provides a highlyreusable set of generic tools to do MID. We claim that thetools provide a meta-architecture because instead of enforc-ing one particular architectural style for development, theycan be customized to create systems of widely differentstyles. Figure 2 shows the components found in a typicalMGA application. The shadowed boxes indicate compo-nents that are generic and are customized for a particulardomain.

In the MGA we use a generic Visual Programming Envi-ronment (VPE)[5] for model building. Models are stored inan object-database; another customizable component. Thedomain-specific customization of these components deter-mines how the visual editor behaves, and how the databaseschema is organized. The model interpreters are typicallyhighly domain-specific. Model interpreters transform mod-els into executable code and/or to the input language ofvarious, domain-specific analysis tools. For run-time sup-port purposes we have successfully used a macro-dataflowbased run-time kernel, that facilitates the dynamic creationof networks of computing objects, even across processors,and the scheduling of those objects.The flexibility with which the MGA can be adopted to var-ious application domains has enabled us to use it in widelydifferent projects during the last 10 years. A selected list ofsystems developed using the MGA is as follows:DTool[7] and RDS: The MGA was used as the softwareframework for a model-integrated robust real-time diagnos-

tic system (RDS) and a diagnosability and testability anal-ysis tool (DTool). The tools are used by Boeing on the In-ternational Space Station Alpha (ISSA) program to evaluatedetectability, distinguishability, and predictability of faultsgiven on-line sensor allocation and built-in-test coverage(BIT). In the case of RDS[8], the models are interpreted andthe software for the RDS is generated automatically. TheRDS implements algorithms that provide timely diagnosisfor complex systems, even in the case of sensor failures.IPCS: The Intelligent Process Control System (IPCS) is anon-line problem-solving environment and decision supporttool for process and production management. The centralconcepts of IPCS are models of the plant and the processengineering activities. Plant models include a variety ofmodeling views, including process flow sheets, static anddynamic process equations, finite-state models, failure prop-agations, equipment structure, etc. Activity models cover awide range of tasks related to process and production man-agement, such as, for instance, analysis of process opera-tions. The activity models are automatically translated intoexecutable software. The IPCS system is actively used at DuPont Old Hickory,TN plant for the development of commer-cial applications, including monitoring, sensor data valida-tion, on-line process simulation, and process diagnosis[4].CADDMAS: Computer Assisted Dynamic Data Monitor-ing and Analysis System. The MGA is the underlying soft-ware technology for the Computer Aided Dynamic DataMonitoring System (CADDMAS) developed in close coop-eration with the USAF Arnold Engineering and Develop-ment Center (AEDC). CADDMAS provides real-time vi-bration analysis for 48 channels of 50 kHz bandwidth usinga heterogeneous network of nearly 100 processors [1][6].In the CADDMAS application, the modeling environmentsupports the hierarchical modeling of signal flow graphs,hardware resources, and resource limitations[1]. A modelinterpreter synthesizes the complex executable program andconfigures the parallel computing platform.

3. A Practical System: SSPF

In this section, we describe the functionalities, require-ments, design and development of the application of MIDtowards providing a problem-solving environment and de-cision support tools in the context of discrete manufacturingoperations at Saturn Corporation. The Saturn Site Produc-tion Flow (SSPF) system is a client-server application de-signed to meet an initiative within Saturn Manufacturingto increase the number of cars built utilizing existing man-ufacturing facilities and processes. The primary focus oftools and services provided by SSPF is the flow of mate-rial throughout the production facility (site-wide productionflow). SSPF is intended to provide an integrated problem-solving environment which presents consistent and pertinent

information,� and analysis and decision support services thatare needed for informed decision making by the team mem-bers and leaders within Saturn.

� � � � � � � � � � � � � � � � � �

SSPF is designed to be an application that evolves easily.The functionalities described below represent the capabili-ties of the system that have already been identified and havebeen implemented or are currently under development. Inthe future, the requirements and functionalities of the sys-tem are expected to grow considerably.Data Acquisition. SSPF functions involve real-time col-lection, presentation, storage, retrieval, and analysis of data.There is a data rich environment at Saturn based on tradi-tional process monitoring and control (PM&C). The databeing measured consists of production counts, downtimes,bank counts, and other production related information. Datacan be presented on screens, using an existing data acquisi-tion and display package. However, in the absence of anystructured plant models to guide the data collection, log-ging and presentation, the enormous volume of data presentsconsiderable difficulties in using the system for monitoringsite-wide status and for performing simulations and otherdecision making analyses.Data Storage and Retrieval. Time is an essential facil-ity in understanding the dynamics of production flow. Thestored data contains detailed histories for every process andbuffer in the plant. Furthermore, summarized informationfor a shift, day, week and month is maintained. Even thoughSaturn currently has systems in place that log and retrievethe production data, the practical usability of this data islimited: access to data is very difficult. SSPF stores the rawdata and processed information in a structured manner usinga relational database (Microsoft SQL/Server). The databaseschemas and the interfaces to the database are generatedautomatically from the plant models, thereby providing theframework for easy access and maintenance of the database.Graphical User Interface. The primary purpose of SSPFis to provide the users with current (real-time) and historicalproduction data, which can be used for various purposes –monitoring, analysis, etc. For presenting the data, SSPFincludes a Graphical User Interface (GUI), which is config-ured from the plant models.

Figure 3 shows the SSPF GUI with hierarchical naviga-tion, drop down boxes and detailed textual report. On theleft, the process hierarchy is shown, which allows the user togo to any section of the plant and examine it. On the right theGUI layout for Vehicle Initial Build, as synthe-sized from the models, and the textual report of productionrelated data is shown.

Figure 3. SSPF GUI

� � � � � � � � � � � � � � � � � � � � � � �

The SSPF application offers a structured view of the datarepresenting the state of the manufacturing processes. Thisstructured view and the related visualization services cre-ate a tight conceptual relationship between the plant andthe SSPF software. In this section, we summarize the keymodeling concepts that are used for defining the SSPF appli-cation and that are also provided for the users of the system.BackgroundThe manufacturing plant is viewed as an aggregate of pro-cesses and buffers. Processes represent the operations re-quired for making a car. Associated with each processare certain measurements that relate to the productivity ofthe process. Examples of such measurements are: cycle-time, production count (how many parts were assembled),Work In Process (WIP) (how many parts are currently beingworked on), production downtime (equipment breakdown),etc. Buffers (or banks) lie between processes and hold partsand/or sub-assemblies that are produced by an upstreamprocess before they are consumed by a downstream process.

To model the Saturn site in terms of its productionprocesses and business organizations, a special modelingparadigm was developed, that utilizes four kinds of models:(1) Production Models, (2) Organization Models, (3) Activ-ity Models, and (4) Resource Models. Production modelsare used to represent the production flow at Saturn. The Or-ganization models are used to represent the business units atSaturn and to establish relationships between business unitsand production units. Activity models are used to configurethe SSPF activities while resource models describe the al-location of SSPF activities to workstations. Here we brieflydescribe the first kind of models only.Production Models Production models hierarchically de-

Figure 4. Structural Aspect for Vehicle InitialBuild

scribe the production flow of Saturn Plant in terms ofprocesses and buffers. A process represents a produc-tion entity in which production and/or assembly opera-tions are performed. A process can be a leaf process, e.g.,Hardware 310, or it may be an aggregate process, e.g.,Vehicle Initial Build. Aggregate processes con-sist of other (leaf and/or aggregate) processes and buffers.Buffers represent the banks between processes, e.g., 300,which is the bank between processes Hardware 200Eand Hardware 310 (see Figure 4). A process may haveinput and output conveyors. These act as interface to buffersand other processes and are used to connect banks and pro-cesses together.

� � � � � � � � � ! " # $ % ! $ & % ' ( ) * + , - + ( % ( $. % ( % ' $ # + (

There are three main parts to the SSPF system as shownin Figure 5:Model-Integrated Programs Synthesis (MIPS) Environment:This consists of the Visual Programming Environment(VPE) also referred to as the Graphical Model Builder(GMB) , Model Database and the Application Generator(AG).SSPF Server: This consists of the Real-Time Data Server(RTDS), Historical Data Server (HTDS), Cimplicity Inter-face, a Cimplicity project bridge (SSPFPB) (for PM&C),ODBC Interface and one or more MS/SQL Server andMS/SQL Database.SSPF Client: This consists of the Client Data Handler andthe Client GUI.

The Application Generator (AG) translates the SSPFmodels into the executable. This was accomplished as fol-lows.1. Configurable run-time libraries and programs were devel-oped, which get their configuration information from con-

Databases

Pentium/Windows NTi86/Windows 95

Client GUI

VPE

/ 0 1 2 3Client Data

Database(OODB)4 5567 89

:7 ;<= ><>?9: ;?

DEC Alpha/Windows NT

MS/SQLServer

MS/SQL

Point Bridge

FDDI

Handler

ODBC Interface

HistoricalData Server

Real-timeData Server

CimplicityInterface

CimplicityProject

(SSPFPB)

(MFS8)

ManagerShift

Figure 5. SSPF Architecture

figuration files produced by the AG. These components im-plement generic functionalities (e.g. interface to the dataacquisition system, user interface, etc.), that can be instan-tiated according to the contents of models.2. Schemas for storing production data were defined. At thistime, this is a manual process. In the future, these schemaswill also be generated from the models.3. AG traverses the model database, extracting the relevantinformation and produces a number of configuration filesand SQL script files.4. The configuration files are read by the SSPF componentsto build internal data structures, thus reflecting exactly whatis in the models.5. The SQL scripts are executed by the SQL/Server. TheSQL scripts fill in the rows for the tables with essentialinformation about the processes, buffers, etc. in the plant.

If the models are changed to reflect changes in the plant,only the last three steps need to performed. If a change in thefunctionality of SSPF is desired, the first two (and possiblythe last three) steps need to be performed.

4. Experiences

The SSPF project was started in September of 1995, withan Engineering Study and preliminary design. By the end ofthe year, a prototype was developed, with about one-third ofthe plant modeled. During 1996, the prototype was movedtowards a production release. Some of the changes werenecessitated by the integration process, but most were justdue to added functionalities. A large part of the effort sinceApril 1996 was spent on building the complete models of theplant. The modeling phase involved consulting with Saturnpersonnel, and then putting this information into the models.

SSPF@ was put into production release in the first week ofAugust 1996.

We learned many lessons during our system integrationefforts:

A A large part of the effort was required for modeling ofthe plant. This is not surprising since the applicationitself is generated from the models.

A Using the MID approach helped us considerably inverifying and testing the application. Before goinginto production release, SSPF Beta release was on-lineduring the model building phase. This allowed us toverify the application and the models.

A Due to iterations on functional specifications for SSPF,many times during the integration phase, requirementsand/or enhancements in the functionality of SSPF wereadded. We had a very quick turn-around time on thesesince all it required was a change in one configurablecomponent followed by re-generation of the applica-tion. Without the use of MID, trying to keep an appli-cation upgrade consistent for all the processes (and thebuffers) would be a very difficult and costly task.

A Since the data acquisition systems in different sectionsof the plant were implemented by different people, wehad to deal with the idiosyncrasies of these implementa-tions. Being able to capture this information in modelsalso helped considerably.

5. Other Approaches

The benefits of software modeling and generating soft-ware from models (to facilitate rapid development) has beenknown for some time. The importance of domain model-ing in the software development process has been recentlyrecognized[3][2].

Many of the concepts developed in [3] are present inour toolset, the MGA. Just like in [2], the domain-specificmodels play an essential role. What makes our approachdifferent, however, is the explicit model interpreter com-ponent, that decouples the execution of the system fromthe models. In a sense, our model interpreters are similarto component generators[9]: they instantiate and configuregeneric components and templates, although our processmay be executed at run-time.

6. Conclusions

Model-Integrated Development shows the following ad-vantages in the software and system development process:

(1) It establishes a software engineering process that pro-motes designing for change. (2) The process shifts the en-gineering focus from implementing point solutions to cap-turing and representing the relationship between problemsand solutions. (3) It supports the applications with model-integrated program synthesis environments offering a gooddeal of end-user programmability. We have found that thecritical issue in system acceptance has been to facilitate do-main specific modeling. This need has led us to followan architecture-based tool development strategy that helpsseparate the generic and domain/application specific systemcomponents. The Multigraph Architecture has proven to beefficient in creating domain specific model-integrated pro-gram synthesis environments for several major applications.

7. Acknowledgements

The SSPF project has been supported by Saturn Corpora-tion. The general MGA research has been supported, in part,by USAF, NASA, Boeing, Du Pont, Sverdrup, and Vander-bilt University. Their support is gratefully acknowledged.

References

[1] Abbott, B. and et al. Model-based approach for softwaresynthesis. IEEE Software, pages 42–53, May 1993.

[2] Ganti, M. and et al. An object-oriented software applicationarchitecture. Proc. of the ICSE-12, pages 212–200, March1990.

[3] Iscoe, N. and et al. Domain modeling for software engineer-ing. Proc. of the ICSE-13, pages 340–343, May 1991.

[4] Karsai, G. and et al. Model-embedded problem solv-ing environment for chemical engineering. Proc. of IEEEICECCS’95, pages 227–234, 1995.

[5] Karsai,G. A configurable visual programming environment:A tool for domain-specific programming. IEEE Computer,pages 36–44, March 1995.

[6] Ledeczi, A. and et al. Modeling paradigm for parallel signalprocessing. The Australian Computer Journal, 27(3):92–102, August 1995.

[7] Misra, A. and et al. Diagnosability of dynamical systems.Proc. of the Third International Workshop on Principles ofDiagnosis, pages 239–244, 1992.

[8] Misra, A. and et al. Robust diagnostics:structural redun-dancy approach. Proc. of Knowledge Based AI Systems inAerospace and Industry, SPIE’s Symposium on IntelligentSystems, pages 249–260, 1994.

[9] S. B. Ornburn and R. J. LeBlanc. Building, modifying, andusing component generators. Proc. of the ICSE-15, pages391–404, Apr 1993.

[10] Sztipanovits, J. and et al. Multigraph: An architecture formodel-integrated computing. Proc. of IEEE ICECCS’95,pages 361–368, 1995.