0018-9162/06/$20.00 © 2006 IEEE February 2006 33P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y

C O V E R F E A T U R E

system is generated. A popular variant of MDD is theObject Management Group’s Model-Driven Architec-ture (MDA),1 which represents systems using OMG’sgeneral-purpose Unified Modeling Language (along withspecific profiles) and transforms these models into arti-facts that run on a variety of platforms like EJB, .NET,and CCM.

Unlike MDA, Model-Integrated Computing (MIC),2

a variant of MDD, uses domain-specific modeling lan-guages (DSMLs) to represent system elements and theirrelationships as well as their transformations to plat-form-specific artifacts. We have successfully applied theMIC concept to develop several DSML tool suites. Here,we focus on two:

• Platform-Independent Component ModelingLanguage (PICML), which assists in developing,configuring, and deploying systems using compo-nent middleware technology such as CCM; and

• Embedded Control Systems Language (ECSL),which supports development of distributed embed-ded automotive applications.

Both of these tool suites are built using the GenericModeling Environment (GME),3 an open source,metaprogrammable, domain-specific design environmentthat developers use to create both DSMLs and modelsthat conform to these DSMLs within the same graphi-cal environment.

Model-driven development is an emerging paradigm that improves the software

development life cycle, particularly for large software systems, by providing a higher

level of abstraction for system design than is possible with third-generation

programming languages.

Krishnakumar Balasubramanian, Aniruddha Gokhale, Gabor Karsai,Janos Sztipanovits, and Sandeep Neema Vanderbilt University

H istorically, software development methodologieshave focused more on improving tools for systemdevelopment than on developing tools that assistwith system composition and integration. Com-ponent-based middleware like Enterprise Java-

Beans (EJB), Microsoft .NET, and the CORBA Compo-nent Model (CCM) have helped improve softwarereusability through component abstraction. However, asdevelopers have adopted these commercial off-the-shelftechnologies, a wide gap has emerged between the avail-ability and sophistication of standard software develop-ment tools like compilers and debuggers, and the toolsthat developers use to compose, analyze, and test a com-plete system or system of systems. As a result, developerscontinue to accomplish system integration using ad hocmethods without the support of automated tools.

Model-driven development is an emerging paradigmthat solves numerous problems associated with the com-position and integration of large-scale systems whileleveraging advances in software development tech-nologies such as component-based middleware. MDDelevates software development to a higher level ofabstraction than is possible with third-generation pro-gramming languages.

MODEL-DRIVEN DEVELOPMENTMDD uses models to represent a system’s elements

and their relationships. Models serve as input and out-put at all stages of system development until the final

Developing ApplicationsUsing Model-Driven Design Environments

34 Computer

DOMAIN-SPECIFIC MODELING LANGUAGESDSMLs are the backbone of model-integrated com-

puting. A DSML can range from something that is veryspecific, such as the elements of a radar system, to some-thing as broad as a component-based middleware appli-cation built using platforms such as EJB or CCM. Thekey idea behind a DSML is its ability to capture domainelements as first-class objects. A DSML can be viewed asa five tuple:4

• a concrete syntax defining the specific notation (tex-tual or graphical) used to express domain elements;

• an abstract syntax defining the concepts, relation-ships, and integrity constraints available in the lan-guage;

• a semantic domain defining the formalism used tomap the semantics of the models to a particulardomain;

• a syntactic mapping assigning syntactic constructs(graphical or textual) to elements of the abstract syn-tax; and

• a semantic mapping relating the syntactic conceptsto the semantic domain.

Thus, the abstract syntax determines all syntacticallycorrect sentences—or models—in the language. A

DSML is also known as a metamodel,because a DSML is itself a model that definesall the possible models that developers canbuild using it.

CREATING A DSMLDSMLs are defined visually in GME. The

first step is to identify the different domainelements and their relationships that wewant to model, which is usually done withiterative input from a domain expert. AnyMDD tool infrastructure should allow mod-ification of the elements (or relationshipsamong elements) with ease.

Second, we map the domain elements toGME concepts like models and atoms, asdescribed in the “Generic Modeling Environ-ment” sidebar. This process is similar to defin-ing types in a programming language likeC/C++. To capture the DSML’s concrete syn-tax, developers define the types in the DSML.

With the mapping of domain elements toGME concepts, UML class diagrams repre-sent the DSML elements as shown in Figure 1.With GME, users can customize the visual-ization of DSML elements—that is, its con-crete syntax—using a decorator, a componentwritten in a traditional programming lan-guage that implements a set of standard call-back interfaces. Once a decorator is registered

with GME, the environment invokes the callbacks when-ever it needs to display the element.

Using UML class diagrams as the notation for aDSML’s concrete syntax, developers can capture someassociation between elements because semantics like car-dinality can be sufficiently represented in UML. To fur-ther constrain associations, GME uses OMG’s ObjectConstraint Language5 to provide a built-in constraintmanager, as Figure 2 shows. Since they do not take sys-tem dynamics into account, DSML semantics usingOCL constraints are static.

After defining the DSML’s elements and its associatedstatic semantics, the developer instructs GME to gener-ate a customized DSML environment using a processcalled metainterpretation. This process takes the defin-ition of the DSML from the previous step; runs a set ofstandard transformations ensuring consistency (as doesa traditional compiler); and creates a paradigm file defin-ing the DSML, which is then registered with GME. It isnow possible to create models conforming to the DSMLusing GME.

Although we have defined the elements, the relation-ships, and the DSML’s static semantics, we also mustdefine dynamic semantics to make the DSML useful forcomplex real-world applications. A DSML’s dynamicsemantics can be enforced by applying model interpreters

Generic Modeling EnvironmentGME is an open source, visual, configurable design environment for

creating domain-specific modeling languages (DSMLs) and programsynthesis environments (http://escher.isis.vanderbilt.edu). One ofGME’s unique features is that it is metaprogrammable—that is, GME isused not only to build DSMLs but also to build models that conform toa DSML. In fact, MetaGME, the GME environment used to build DSMLs,is itself built using another DSML—or metametamodel. GME providesthe following elements to define a DSML:

• project: the top-level container in a DSML;• folders: used to group collections of similar elements together;• atoms: the indivisible elements of a DSML, used to represent the

leaf-level elements in a DSML;• models: the compound objects in a DSML, used to contain different

types of elements—also known as parts—like references, sets,atoms, and connections;

• aspects: used primarily to provide a different viewpoint of the samemodel (every part of a model is associated with an aspect);

• connections: used to represent relationships between domain ele-ments;

• references: used to refer to other elements in different portions ofa DSML hierarchy (unlike connections, which can be used to con-nect elements within a model); and

• sets: containers whose elements are defined within the sameaspect and have the same container as the owner.

written using a traditional pro-gramming language like C++,Python, or Java and registered withGME. When the interpreter is in-voked, GME gives it access to themodel hierarchy, and it can performdifferent kinds of validation andgenerative operations on the mod-els. One such operation can includegenerating platform-specific arti-facts directly from the models.

APPLYING MIC TOCOMPONENT-BASEDAPPLICATIONS

A common trend in componentmiddleware technology is the useof metadata to capture applicationproperties that were previouslytightly coupled with the imple-mentation. This allows for declar-ative specification of an applicationusing platform-agnostic technolo-gies like XML and then automaticdeployment and configuration.

Higher-level abstractions like vir-tual machines, execution contain-ers, and extra information aboutsystems via rich metadata has adirect impact in enabling people tobuild systems that are more het-erogeneous than previously possi-ble. However, this also increasesthe amount of information thatmust be managed by the systemdeveloper as well as the complex-ity of system integration.

Infrastructure for managing suchcomplex deployment was essentiallylacking in previous-generation mid-dleware, and most deploymentswere done on an ad hoc basis with-out much infrastructure reuse orpotential for rigorous system verifi-cation and validation. This lack ofsimplification and automation has hindered the adop-tion—and ostensible benefits—of component middlewaretechnologies.

PICMLTo address these problems, we developed PICML, an

open source DSML available for download as part ofthe CoSMIC MDD framework (www.dre.vanderbilt.edu/CoSMIC). Developers of component-based systemscan use PICML to define application interfaces, quality-of-service (QoS) parameters, and system-software build-

ing rules, as well as to generate metadata and XMLdescriptor files that enable automated system deploy-ment. PICML also provides capabilities to handle com-plex component engineering tasks, such as multi-aspectvisualization of components and subsystem interactions,component deployment planning, and hierarchical mod-eling of component assemblies.

Currently, PICML is used in conjunction with theComponent-Integrated ACE ORB (CIAO)—our CCMimplementation—and our Deployment and Configura-tion Engine (DAnCE),6 a QoS-enabled deployment

February 2006 35

Figure 1. Domain mapping. With the Generic Modeling Environment, users cancustomize a domain-specific modeling language’s concrete syntax.

Figure 2. Defining static semantics in GME.To further constrain associations, GME usesOMG’s Object Constraint Language to provide a built-in constraint manager.

36 Computer

engine. However, PICML’s design has beendriven by the goal of integrating systemsbuilt using different component technologieslike .NET and EJB.

PICML is defined as a metamodel in GMEfor describing components, types of allowedinterconnections between components, andtypes of component metadata for deploy-ment. From this metamodel, the metamodelinterpreter generates 20,000 lines of C++code representing the modeling language ele-ments as equivalent C++ types. This gener-ated code allows manipulation of modelingelements—that is, instances of C++ languagetypes—and forms the basis for writing model interpreters, which traverse the modelhierarchy to generate XML-based deploy-ment descriptors. As the “Deployment Meta-data” sidebar describes, these descriptorssupport OMG’s Deployment and Configura-tion specification.7

Figure 3 shows the typical steps involved incomponent-based application developmentusing PICML’s MDD approach:

Assembly

Assembly

Assembly

Deployment

DAnCEframework

(5) Deploymentplanning

Componentdeployer

Specification

Composition Generation

Plan

ning

Assembly

(2) Interactiondefinition

(1) I

nter

face

defin

ition

(3)Hierarchical

composition

Component

Resourcerequirements Properties

Implementation Implementation Implementation

Componentdeveloper

Componentassembler

Component

Componentassembly

Component package

(4)D

escr

iptor

gene

ratio

n

Componentpackager

Component

Component Component

Component

Componentassembly

Component

Component Component

Component

Componentassembly

Component

Component Component

PICML

Figure 3. Model-driven development of component-based applications using PICML.The infrastructure uses artifacts output fromPICML to carry out the different stages of component application deployment.

Deployment MetadataPICML generates the following types of deployment descriptors

based on the OMG Deployment and Configuration specification:

• component interface descriptor (.ccd): describes a single component’sinterfaces, ports, and attributes;

• implementation artifact descriptor (.iad):describes a single component’simplementation artifacts—for example,DLLs and executables;

• component implementation descriptor (.cid): describes a specificimplementation of a component interface and also contains component interconnection information;

• component package descriptor (.cpd): describes a single component’smultiple alternative implementations—for example, different operating systems;

• package configuration descriptor (.pcd): describes a componentpackage configured for a particular requirement;

• component deployment plan (.cdp): describes the plan that guides theruntime deployment; and

• component domain descriptor (.cdd): describes the deployment target—the nodes and networks—on which the components areto be deployed.

1. Visual component interface definition. UsingPICML, we create a set of component interface andother data type definitions in CORBA’s Interface Defini-tion Language. In this step, we can either import exist-ing IDL definitions or create new ones from scratch.

To import existing definitions, the IDL importer caneasily migrate existing CORBA to PICML. The importertakes IDL files as input, maps their contents to theappropriate PICML model elements, and generates asingle XML file that can be imported as a PICML model.To design new interfaces, PICML’s graphical modelingenvironment supports using an intuitive drag-and-droptechnique, making this processlargely self-explanatory and inde-pendent of platform-specific techni-cal knowledge.

2. Valid component interactiondefinition. By elevating the level ofabstraction, the well-formednessrules of DSMLs like PICML actuallycapture semantic information suchas constraints on model compositionand allowed interactions.

There is a significant difference in the early detectionof errors in the MDD paradigm compared with tradi-tional object-oriented or procedural development usinga conventional compiler. PICML uses OCL constraintsto define the modeling language’s static semantics,thereby disallowing invalid systems. In other words,PICML enforces the correct-by-construction approachto system development.

3. Hierarchical composition. In a complex system withthousands of components, visualization becomes anissue because of the practical limitations of displays aswell as human cognition. Without support for hierar-chical composition, observing and understanding sys-tem representations in a visual medium does not scale.

To increase scalability, PICML defines a hierarchy thatdevelopers can use to view their system at multiple lev-els of detail depending upon their needs. With hierar-chical composition, developers can both visualize theirsystems and compose systems from smaller subsystems.This feature supports unlimited levels of hierarchy—constrained only by the physical memory of the systemused to build models—and promotes the reuse of com-ponent assemblies. Therefore, developers can usePICML to develop repositories of predefined compo-nents and subsystems.

The hierarchical composition capabilities that PICMLprovides are only a logical abstraction: Deploymentplans generated from PICML flatten out the hierarchy toconnect the two destination ports directly, thereby ensur-ing that no extra communication overhead is attributedto this abstraction at runtime.

4. Valid deployment descriptor generation. In addi-tion to ensuring design-time integrity of systems built

using OCL constraints, PICML also generates thecomplete set of deployment descriptors needed asinput to the component deployment mechanisms.These descriptors conform to the OMG D&C specifi-cation7 and are described in the “DeploymentMetadata” sidebar.

5. Deployment planning. Systems are often deployedin heterogeneous execution environments. To supportthese needs, PICML can specify the target environment,which includes nodes, interconnects among nodes, andbridges among interconnects. Once the target environ-ment is specified, developers can allocate component

instances onto the target environ-ment’s various nodes. PICML cur-rently provides facilities for specify-ing static allocation of componentsto nodes.

EMBEDDED DESIGN USING ECSL

The model-based approach forembedded systems development hasheretofore been confined to the func-

tional aspects of the system design and is restricted to alimited suite of tools—most notably the Mathworksfamily of Matlab, Simulink, and Stateflow tools.

Simulink and Stateflow are powerful graphical systemdesign tools for modeling and simulating continuousand discrete event-based behavior in a dynamic system.However, these tools by no means cover the entire spec-trum of embedded systems development.

The embedded systems development process includesseveral other complex activities such as requirementsspecification, verification, mapping onto a distributedplatform, scheduling, performance analysis, and syn-thesis. Although some existing tools individually sup-port one or more of these development activities,integration with the Mathworks suite is often lacking.This makes it difficult to maintain a consistent view ofthe system as the design progresses and requires signif-icant manual effort to create different representationsof the same system.

To address these deficiencies, our Embedded ControlSystems Language (ECSL) supports

• annotation of structural design, software-compo-nent design, and behavior implementation to sup-ply information needed by a code generator;

• creation of hardware-topology design models, electronic control unit (ECU)-design models, andfirmware-implementation design models; and

• creation of deployment models that capture com-ponent and communication mapping.

ECSL also imports existing Simulink/Stateflow (SL/SF)models into the GME environment.

February 2006 37

PICML defines a hierarchy that developers can use to

view their system at multiplelevels of detail depending

upon their needs.

38 Computer

Embedded automotive applicationsDesigning and developing embedded automotive sys-

tems is becoming notoriously difficult. In recent years,there has been an explosion in the scale and complexityof these systems, with a push toward drive-by-wire tech-nologies, increasing feature levels, and increasing capa-bilities in embedded computing platforms. To addressthis level of complexity, the automotive industry has ingeneral embraced the model-based approach for embed-ded systems development.

Figure 4 depicts the activities in an automotive embed-ded systems development process as supported by theECSL tools. Each rectangular block denotes a particu-lar activity, and arrows indicate the workflow betweendifferent activities. Activities can roughly be grouped inthree blocks: hardware design, software design, andmapping. (Requirements engineering is not within thescope of this tool suite, although it is the basis for mostof the modeling and development activities.)

Hardware design includes specifying ECUs in a net-work and their connections with buses and defining anarchitectural topology of the distributed embedded plat-form. Refinements of this activity include designing indi-vidual ECUs, selecting the processors, and determiningthe memory and I/O requirements.

Software design includes

• structural design: the hierarchical decomposition of the embedded system into subsystems from a func-tional viewpoint;

• component design: another form of decomposition, not independent of the functional decomposition, deal-ing with more classical embedded software concerns such as real-time requirements, real-time tasks, peri-odicity, deadlines, and scheduling; and

• functional/behavioral design: the elaboration of the hierarchical structural design’s leaf elements in terms of a synthesizable realization.

Mapping includes activities involvingboth software and hardware objects,such as decisions regarding the deploy-ment of certain complete or partial func-tions to hardware nodes that are part ofthe network and the assignment of sig-nals to bus messages.

The abstract design process shown inFigure 4 is made concrete by a number ofsupporting tools, including GME/ECSL,ML2ECSL, and ECSL/CG. GME/ECSLis the Generic Modeling Environment

tailored to support the ECSL modeling language. TheML2ECSL translator imports SL/SF models into theECSL environment. Finally, ECSL/CG is a specializedcode generator that produces various low-level produc-tion artifacts from ECSL models, including real-timeoperating system configuration, firmware configurationcode, and behavioral implementation of the components.

ECSL conceptsECSL, a graphical modeling language built using

GME that contains modeling concepts for design activ-ities, comprises a suite of sublanguages.

Functional modeling. ECSL’s SL/SF sublanguagesmirror the capabilities found in the Simulink andStateflow languages such that all SL/SF models can beimported into the GME/ECSL environment. Simulinkfollows a dataflow-diagram visual notation, whileStateflow supports Statechart-like hierarchical finitestate machines.

Component modeling. This sublanguage allows soft-ware modeling in two stages: integrating and then com-ponentizing SL/SF models. Componentization is specifiedusing the GME containment and reference capabilities:Components are GME models that contain references toelements of the functional model imported from SL/SF.

Code generation

Structural design

SW-component design

Behaviorimplementation

Behaviorcode generation

Software design(refinement)

SL/SF

Componentmapping

Communicationmapping

System codegeneration/ integration

Electronic control unitintegration

Mapping

HW topologydesign

Electronic control unit

design

Firmwareimplementation

Firmwarecode generation

Hardware design

GME/ECSL

ECSL/CG

Requirements analysis

ML2ECSL

Figure 4. ECSL process. Each rectangular block denotes a particular activity, andarrows indicate the workflow between different activities. Activities can roughlybe grouped in three blocks: hardware design, software design, and mapping.

Components consist ofports that allow the spec-ification of intercompo-nent communication, aswell as interfaces to phys-ical devices including sen-sors and actuators. Portattributes capture re-quired communicationproperties such as datatype, scaling, and bitwidth. The intracompo-nent dataflow exists with-in the imported functionalmodels. The designerintroduces the intercom-ponent dataflow aftercomponentizing the im-ported models.

Hardware topologymodeling. Designers canuse ECSL’s hardwaremodeling to specify thehardware topology, in-cluding the processorsand communication linksbetween the processors.ECU models represent specific processors and have twoports representing the I/O channels and the bus connec-tions. ECU firmware specifics with respect to memorysize and CPU speed are captured with attributes. I/Ochannel ports come in two variants: sensor ports andactuator ports. Bus models represent communicationpathways used to connect ECUs and are expressed asGME atoms whose attributes specify various physicalcommunication system properties such as bit rates.

Deployment (mapping) modeling. This modelingsublanguage captures how software components aredeployed on the hardware. The designer can use theECU model’s deployment aspect to map the softwarecomponent to the ECU using GME’s reference concept.

Note that deployment models are separate from soft-ware models, thus allowing the reuse of software mod-els in different hardware architectures. Furthermore,component ports are connected to ECU ports to indi-cate how the component software interfaces map toactual sensors, actuators, and buses.

Generating code and other artifactsAs Figure 5 shows, the ECSL/CG tool is a code gen-

erator that produces code artifacts necessary for systemimplementation. The tool generates the following typesof files:

• an OIL (OSEK Implementation Language) file foreach ECU node that includes a listing of all used

OSEK (www.osek-vdx.org) objects and their relations;

• one or more C files implementing OSEK tasks; • application-behavior code called out from within a

task frame; and • glue code comprising one or more C code/header

files that resolve the calls to the controller area net-work (CAN) driver or the firmware to provide accessto CAN signals or hardware I/O signals.

Together, these generated artifacts comprise the entireapplication code. While the code generator supports syn-thesis of application-behavior code, it is feasible to link inexternally supplied application-behavior code, which canbe either handwritten or generated using a third-partytool. Additional framework code is generated using ven-dor-supplied tools such as those from Vektor Informatikthat configure the controller area network bus. Also,developers can use the OSEK vendor-supplied tools toprocess the generated OIL files that configure the oper-ating system and set up the tasks and task properties.

We have evaluated the code generator with severalexamples of small to medium complexity such as adefroster controller and a steering and braking con-troller. The generated code for these examples was func-tionally correct and bug-free. We can systematicallyderive the correctness based on the glue code construc-tion; however, a formal proof of correctness of the appli-cation-behavior code generation is an open problem and

February 2006 39

OSEK OSOIL file

OSEK OSspecific .h files

OSEK OSCANoe emulation

Generatecode

OSEK applicationtasks and code

Application-behavior code

Extendedsimulink/stateflow model

NodeLayer-DLLfor CANoe

CANoe

Compile+link

Glue code.c, .h files

CAN driverconfiguration

CAN driverCANoe emulation

Configure

Generated by Vanderbilt code generator

Vector tools or standard code modules

For each HW node

Figure 5. ECSL code generation.The ECSL/CG tool produces code artifacts necessary for systemimplementation. CAN = controller area network.

40 Computer

remains a work in progress. We are also investigatingtechniques for automatically generating a test suite forthe application behavior code generation.

The automotive application domain that the tools tar-get emphasizes the readability and traceability of gen-erated code. Therefore, the code generator does notperform any aggressive optimization on the Statechartsspecifying application component behavior.

M odel-driven development is a promising para-digm for tackling system composition and inte-gration challenges. MDD elevates the abstraction

level of software development and bridges the gapbetween technology domains by allowing domainexperts (who may not be experts in software develop-ment) to design and build systems. This higher level ofabstraction also allows transformation between modelsin different domains without resorting to low-level inte-gration solutions such as standard network protocols.

The Platform-Independent Component ModelingLanguage, a DSML built using GME, simplifies andautomates many activities associated with developingand deploying component-based systems. The EmbeddedControl Systems Language is a DSML tool suite that sup-ports development of distributed embedded automotivesystems by interfacing with existing engineering tools,while adding new capabilities to support deployment ondistributed platforms and integration of model verifica-tion tools into the development process.

MDD ensures the semantic consistency of systems byenforcing the correct-by-construction philosophy. It alsosolves many of the accidental complexities that ariseduring system integration due to the heterogeneity ofthe underlying component middleware technologies.With improvements in generative techniques, MDD has the potential to automate code generation just ascompilers replaced assembly language/machine-codeprogramming. �

References1. D. Frankel, Model Driven Architecture: Applying MDA to

Enterprise Computing, John Wiley & Sons, 2003.2. J. Sztipanovits and G. Karsai, “Model-Integrated Comput-

ing,” Computer, Apr. 1997, pp. 110-112.3. A. Ledeczi et al., “Composing Domain-Specific Design Envi-

ronments,” Computer, Nov. 2001, pp. 44-51.4. G. Karsai et al., “Model-Integrated Development of Embed-

ded Software,” Proc. IEEE, Jan. 2003, pp. 145-164.5. Object Management Group, Unified Modeling Language: OCL

version 2.0, OMG document ptc/03-10-14 ed., Oct. 2003.6. G. Deng et al., “DAnCE: A QoS-Enabled Component Deploy-

ment and Configuration Engine,” Proc. 3rd Working Conf.Component Deployment, LNCS 3798, Springer-Verlag, 2005,pp. 67-82.

7. Object Management Group, Deployment and ConfigurationAdopted Submission, OMG document ptc/03-07-08 ed., July2003.

Krishnakumar Balasubramanian is a graduate student inthe Department of Electrical Engineering and ComputerScience at Vanderbilt University. His research interestsinclude model-driven development, deployment and con-figuration of component middleware, and patterns andframeworks for distributed, real-time, and embedded sys-tems development. He received an MS in computer sciencefrom Washington University in St. Louis. He is a studentmember of the IEEE. Contact him at kitty@dre.vanderbilt.edu.

Aniruddha Gokhale is an assistant professor of electricalengineering and computer science at Vanderbilt Universityand a senior research scientist in the Institute for Software-Integrated Systems at Vanderbilt. His research interestsinclude real-time component middleware optimizations,model-driven software development, and distributedresource management. Gokhale received a PhD in com-puter science from Washington University in St. Louis. Heis a member of the IEEE. Contact him at a.gokhale@vanderbilt.edu.

Gabor Karsai is an associate professor of electrical engi-neering and computer science at Vanderbilt University anda senior research scientist in the Institute for Software-Inte-grated Systems at Vanderbilt. He conducts research inmodel-integrated computing. Karsai received a technicaldoctorate degree in electrical engineering from the Techni-cal University of Budapest, Hungary, and a PhD in electri-cal engineering from Vanderbilt University. He is a memberof the IEEE Computer Society. Contact him at gabor.karsai@vanderbilt.edu.

Janos Sztipanovits is the E. Bronson Ingram DistinguishedProfessor of Engineering in the Department of ElectricalEngineering and Computer Science at Vanderbilt Univer-sity. He is founding director of the Institute for Software-Integrated Systems. His research interests include model-integrated computing, structurally adaptive systems, andembedded software and systems. Sztipanovits received adistinguished doctor degree from the Hungarian Academyof Sciences. He is a Fellow of the IEEE. Contact him atjanos.sztipanovits@vanderbilt.edu.

Sandeep Neema is a research assistant professor in the Insti-tute for Software-Integrated Systems at Vanderbilt Univer-sity. His research interests include design space explorationand constraint-based synthesis of parallel/distributed, real-time, embedded systems. Neema received a PhD in electri-cal and computer engineering from Vanderbilt University.He is a member of the IEEE. Contact him at sandeep.k.neema@vanderbilt.edu.