A MODEL MANAGEMENT APPROACH FOR CO-SIMULATION

MODEL EVOLUTION

Xiaochen Zhang and Jan F. Broenink

Centre for Telematics and Information Technology, University of Twente, Enschede, The Netherlands

Keywords:

Multi-disciplinary system, Model management, Co-simulation, Model evolution, Logging mechanisms.

Abstract:

In most of the embedded control system designs, multiple engineering disciplines and various domain-speciﬁc

models are involved, such as mechanical, control, software and hardware models. Close collaboration and well

integration between all domain-speciﬁc models become more and more important for developing dependable

and cost-efﬁcient systems. Moreover, each disciplinary model can be developed and evolved following its own

semantics and development tools in different rates. The inconsistency between models and the evolution of

the collection of models will increase the complexity of design as well as the difﬁculty of maintaining several

models under simultaneous development and changes.

This paper proposes a model management approach for multi-disciplinary systems and co-simulation. Such

model management approach can ensure the model integration and consistency by checking the model inter-

faces attached to each domain model and the protocol deﬁned in a co-simulation contract. It also can keep

track of model evolution along with changing details and making design variants. The concepts of a scenario-

based co-simulation framework and a logging mechanism with graphical representation of the model evolution

process are also explained.

1 INTRODUCTION

Simulating models is a widely used means for veri-

fying the correctness of a system design. For most

model-based embedded control systems, multiple

engineering disciplines and various domain-speciﬁc

models are involved. See, for example, the self-

balancing human transport vehicle (Segway, 2007)

shown in Figure 1, in which the system design re-

quires mechanical models, hardware and software

models, plant model and its control algorithms, as

well as the requirements and a project/product man-

agement system to keep the design on track.

However, even if working on the same system and

towards the same overall goal, engineers from differ-

ent domains intend to use their domain-speciﬁc lan-

guages and tools to interpret the problems, and fo-

cus on that speciﬁc part. For instance, an expert from

the control engineering domain decides to use 20-sim

(Controllab Products, 2010) to simulate the dynamic

behaviours of the system. On the other hand, a soft-

ware engineer intends to use the Overture Tool (Com-

munity, 2010) to implement the logic behaviour of the

system. The traditional way of implementing the sys-

tem is to follow a mono-disciplinary style (Fitzgera-

Figure 1: An example of possible engineering disciplines

required for a self-balancing scooter system (Kuppeveld,

2007).

ld et al., 2010), in which, each engineering group

handles distinct aspects separately and provide inte-

gration after all aspects are ﬁnished. Unfortunately,

this late integration and less support of system-level

overview may cause fatal problems since the impact

168

Zhang X. and F. Broenink J..

A MODEL MANAGEMENT APPROACH FOR CO-SIMULATION MODEL EVOLUTION.

DOI: 10.5220/0003601201680173

In Proceedings of 1st International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH-2011), pages

168-173

ISBN: 978-989-8425-78-2

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

on each discipline is usually exposed late in integra-

tion phase. To support multi-disciplinary system de-

sign, we advocate collaborative modelling and co-

simulation (DESTECS, 2010), in which, systems as

a whole can be veriﬁed in the early stage of their life-

cycle.

In our co-simulation perspective, all models can

be developed and evolved concurrently following

their own semantics and tools in different rates. The

evolution of models naturally occurs during the de-

sign process, but models also evolve due to changes

in requirements. In particular, changes in one model

may have ramiﬁcations on other models since all do-

main models are somehow dependent on each other.

The mismatch of interconnection of co-simulation

models will cause incorrect simulation results. More-

over, the lack of an overall view of a co-simulation

model development process will also slow down the

design speed and the possibility of reusing models.

All these aspects will highly increase the complexity

of system design as well as the difﬁculty of maintain-

ing co-simulation models while evolving.

Hence, our work is aiming at addressing a co-

simulation-oriented model management approach to

ensure model integration and consistency, and prevent

mismatches of model parts. The second goal of the

approach is to keep track of model evolution, such

that various levels of detail and maturity can then be

used to ﬁnd optimal solutions for design challenges,

and support decision making. These services need to

be implemented in tools to manage complexity, struc-

ture the modelling process, and manage concurrent

design.

In this paper, Section 2 provides the key concepts

and model consistency checking method by introduc-

ing the terms model interface and co-simulation con-

tract. Section 3 presents the model management ar-

chitecture overview and its main services. Section

4 explains the two-directional model evolution ap-

proach, and addresses a graphical representation of

the model evolution process and the supporting tool.

The ﬁnal section gives the concluding remarks and a

forward look to the future.

2 KEY CONCEPTS AND MODEL

CONSISTENCY CHECKING

Models are an important organisational resource

(Chao-fan and Qing-Yan, 2009). Since the consti-

tute models of a co-simulation can evolve in differ-

ent speeds through development, the success of run-

ning a co-simulation is supported by synchronising

domain models in a consistent fashion. In this section,

the idea of scenario-based co-simulation is explained.

The deﬁnition of co-model and model interface are in-

troduced as well to ensure the model integration and

consistency checking.

2.1 Scenario-based Co-simulation

In order to execute a co-simulation run, a test scenario

is required to drive the process. A simple scenario

can be thought of as deﬁning a test run for the co-

simulated models. A complex scenario may conﬁgure

multiple co-simulation runs, for example, a parame-

ter in a model is deﬁned within a range to allow pa-

rameter sweeping. Engineers can deﬁne different test

scenarios for the same co-simulation models to verify

and test the system behaviours, and furthermore, the

dependability of the system under extreme situations.

The scenario is linked to the domain models via a

so-called co-model interface, shown in Figure 2. The

co-simulation then can be executed by executing the

domain models according to the co-simulation con-

ﬁguration deﬁned in the scenario, such as the initial

values of certain shared variables and design parame-

ters, or deﬁning system behaviours that should occur

at speciﬁc points in time during the co-simulation run.

2.2 Co-model and Model Interface

Models are normally executable and are the founda-

tion elements in model-based engineering. The con-

cept of a co-model is introduced to integrate different

domain models and exchange data for co-simulation.

The interaction between domain models is achieved

by executing them simultaneously and allowing in-

formation to be shared. The sharable elements are

recorded in a co-simulation contract. Each domain

model is connected to the contract by attaching a

model interface. The structure of a co-model is shown

in Figure 2, in which the co-model is comprised of

a discrete-event (DE) model, a continuous-time (CT)

model, and the co-simulation contract. In this way,

the co-simulation can be veriﬁed by checking whether

the shared elements returned from each model inter-

face match the statements written in the contract.

Figure 2: Co-model structure and scenario-based co-

simulation.

A MODEL MANAGEMENT APPROACH FOR CO-SIMULATION MODEL EVOLUTION

169

Figure 3: Example of model consistency checking in a water level control system design.

2.3 Consistency Checking

The consistency and compatibility of the shared in-

formation are important for co-simulation. Once the

interface of the models are changed, the contract has

to be modiﬁed as well. The model interface for each

of the constituent model can be accessed externally.

Figure 3 shows an example of how the con-

stituent model interfaces connect to the contract and

ensure the consistency in a water level control sys-

tem design. The left-hand side is a discrete-event

model interface, in which the levelSensor.level

and the valveActuator.valveState are connected

to the contract by giving their values to those shared

variables deﬁned in the co-simulation contract, i.e.

the middle code block. The right-hand side is

the continuous-time model interface, in which the

levelIn and valvecontrolOut are connected to the

contract as well through the same identiﬁer.

These interfaces are intended to assist in manag-

ing the models by permitting a degree of static check-

ing on the viability of co-simulation. This ensures

model coherence and consistency, also while the mod-

els evolve. However, the level of information hiding is

currently limited. For example, interface-preserving

changes might nevertheless invalidate the semantics

of a co-model and this only becomes visible at co-

simulation time. This is, unfortunately, not yet cov-

ered by the consistency checking system.

3 MODEL MANAGEMENT

ARCHITECTURE

A traditional model management system usually con-

tains several services such as storage and retrieval of

models, handling of versions and variants of mod-

els, access control, change request management, de-

velopment process management, analysis of the re-

sults of the model if necessary, as well as support for

geographically distributed development (Baharadwaj

et al., 1992). Since we are working with many models

within a cross-domain project, more services of the

model management system should be provided. This

section presents the model management architecture

and its basic components.

In order to fulﬁl the demands of a co-simulation

development, the model management architecture has

to include at least the following three aspects:

The ﬁrst and primary aspect of the model manage-

ment system in our approach is to keep track of the

model development and evolution process of the sys-

tem design in order to deal with the increasing com-

plexity introduced by continuous change of models.

The second aspect is the service towards model in-

terfacing, integration, and consistency checking. The

third aspect is the model base, and its ability to

store, share and exchange data information for co-

simulation purpose.

Together with the components mentioned above,

the proposed overview of the model management ar-

chitecture is illustrated in Figure 4.

The architecture consists of two main parts: a set

of functional facilities and a model base. The model

base can be considered as a model storage system.

Models in the model base can be accessed by each

of the domain-speciﬁc tools. The detailed functional-

ities of each components in the architecture are listed

here:

• Model Base: to share and exchange model infor-

mation that are required by a co-simulation. The

model base can be considered as a data repository.

Models that are stored in the model base are the

ﬁrst step towards model reuse.

• Model Integration: to integrate different domain

models such that designs can be treated and man-

aged as a whole; the concept of co-model is intro-

duced by this function.

• Consistency Checking: to check the consistency

and compatibility of constitute models within a

co-model (via the model interface and contract

introduced in Section 2), and model alternatives

within a model base.

• Model Evolution: to support the model evolution

SIMULTECH 2011 - 1st International Conference on Simulation and Modeling Methodologies, Technologies and

Applications

170

Figure 4: Overview architecture of the model management

approach.

along 2 directions (versions and variants); pro-

vides a top-level overview of the entire developing

process.

• Requirement Tracking: to keep track of require-

ments and its changes throughout the develop-

ment.

• Change Management: to keep track of the process

of model evolution, including model version con-

trol. An automatic way of detecting changes on

all domain models and the method of comparing

model topology and topography differences will

be designed for this service as a part of the model

management system.

• Change Notiﬁcation: to inform the correspond-

ing engineer who is assigned to an authorised

model with notiﬁcation messages when the model

is changed by other engineers.

• Development Logging: to provide a graphical rep-

resentation of the model evolution process.

4 MODEL EVOLUTION

In most complex system developments, requirements

are vague in the beginning and are reﬁned stepwise

towards a more formal representation (Kim and Car-

rington, 2006). The frequently changing requirements

lead to continuously evolving models. In practice, the

maturity of a model grows by adding detailed infor-

mation during the design. On the other hand, it is also

common that engineers intend to try another design

solution which is similar to an existing one and see

which design can maximally fulﬁl the design require-

ments and requires less cost.

In this section, we present an approach of model

evolution along two axes and how this approach, im-

plemented as a tool, helps to handle the complexity of

the co-simulation design process.

Technically, all these models are closely related

and have to be stored in the model base such that

the complete model evolution process can be tracked.

Some of these model evolutions will survive design

choice while others are abandoned, according to con-

clusions drawn from co-simulation results.

4.1 Model Evolution in Two Directions

In practice, it is common that more than one candi-

date design is made for the same development pur-

pose in order to ﬁnd the best design solution. Re-

sults are many versions of models for the same item

of which some are reﬁnements and others are differ-

ent design variants, that is, design alternatives. For

managing co-models, in our terminology, as they de-

veloped through a system’s design history, we dis-

tinguish between alternatives and details. This can

be seen as model evolution along two axes. Design

alternatives are co-models which represent different

solutions to the same problem. They generally dif-

fer from one another in terms of values of parameters,

variables and structure. Taking the water level control

system as an example, suppose that a motor is con-

trolled by the local controller, and used to open and

close a valve. Different types of motors might yield

different results according to the capabilities of that

motor with respect to speed, power or torque, each

being an alternative model. Model variants can be

created by mapping from other model alternatives.

Design details represent reﬁnements of the same

basic co-model. Each alternative can be reﬁned

through many different detailed levels so that each

level represents a design step of a given alternative.

Different than just keep track of all changes on a

model, the detail level is considered as an important

change status of the development. In stead of show-

ing all changes of a model, including small and minor

changes, providing a higher level view of the model

evolution may help engineers to master the develop-

ment process and design decisions based on models,

with possibilities for future model reuse.

Through model evolution, several types of rela-

tions between models are classiﬁed to indicate the

process:

• Evolve steps move a model towards its ﬁnal form.

This may entail the addition of detail to make a

model more competent or more faithful to a pro-

posed implementation. However, evolution steps

can equally well involve the removal of irrelevant

details from models, when it is determined that

these do not contribute to the analysis for which

A MODEL MANAGEMENT APPROACH FOR CO-SIMULATION MODEL EVOLUTION

171

Figure 5: Model evolution process.

the model is constructed.

• Explore steps generate design alternatives; gen-

eration can be by hand or with machine assis-

tance, based on the outcomes of design space ex-

ploration.

• Merge steps integrate and reconcile multiple

changes into one design alternative.

• Baseline steps designate a particular model as sig-

niﬁcant in the development story. We might ex-

pect to see a full set of scenarios, scenario out-

comes, rationale and documentation associated

with such baselines.

Figure 5 illustrates, at an abstract level, an exam-

ple of co-model evolution along detail levels and al-

ternatives dimensions. It shows an extract of an imag-

inary model base in which each block stands for a co-

model. The arrows indicate different types of the re-

lationships between co-models in the structure, each

with different attributes.

The horizontal grey lines show decision points,

marked A to D in Figure 5. At each point, any deci-

sion to perform one of the actions above will be made,

based on the design requirements and simulation re-

sults. For instance, before point A is reached, the

original Co-model 1 is proposed. For documentation

or conﬁguration considerations, Co-model 1 is desig-

nated as a baseline. Through evolution, more compo-

nents might be detailed out, such that the detail level

of Co-model 2 is greater than that of Co-model 1. Be-

tween points B and C, four alternatives are explored

based on the original model. Due to design space ex-

ploration, Co-model 6 may be considered not to ful-

ﬁl certain design requirements as a result of applying

relevant cost functions to its co-simulation test out-

comes. As a result it can be designated a “dead end”.

Other models may be a satisfactory basis for further

exploration. In the example, Co-model 9 is ultimately

designated to be the next baseline.

The above approach is to manage the co-model

evolution life-cycle such that engineers can easily

maintain the entire development process by navigat-

ing the model evolution history. All these co-models

and their evolution process, the relations and the pur-

pose of making the design decisions based on the

models can be tracked.

Based on this approach, a readable document has

to be generated to the engineers to tell the story

of the co-model evolution process. Different detail

levels and different co-model alternatives should be

recorded and retrieved easily from the model base.

Changes and decisions have to be recorded as well.

Therefore, a tool prototype is developed as a proof-

of-concept of this evolution approach.

4.2 Model Development Log and Tool

Support

Development log ﬁles are valuable resources for de-

signing, implementing, testing and documentation

since developers can recall the process of the develop-

ment according to the logged information. The idea

of our logging mechanisms is to provide a graphical

representation of the model evolution process in order

to help understanding the development of especially

large and complex embedded control systems.

Figure 6 shows an example of the basic logging

mechanism. Engineers from different disciplinary do-

mains can develop their responsible models concur-

rently. All modelling information and the simula-

tion results can be stored in the model base. The

model management system can take care of the model

evolution process and the consistency checking. Ac-

cording to the development information stored in the

model base, an top-level overview of the model evo-

lution can then be generated in the “Development Log

Graph” window which is implemented as an Eclipse

plug-in, and shown in the right side of the ﬁgure.

All the blocks in the graph stand for co-models

of different levels of detail in the model base, in this

example, the water level control system model base.

The block in green indicates that the co-model is a

root model of the design alternative, also with a “root”

mark. By default, the root co-model is marked as “im-

portant status” and “co-simulation baseline” indicat-

ing the starting point of this design.

In this example, there are two design alternatives

in the entire development phase. The mark “E” on the

co-model block indicates a design alternative, which

is explored based on this design. The right-hand

side shows the development information of the co-

model, which appears when clicking on the co-model

block. For example, the revision number, author in-

formation, date of design, decision messages of mak-

SIMULTECH 2011 - 1st International Conference on Simulation and Modeling Methodologies, Technologies and

Applications

172

Figure 6: Graphical representation of model evolution logging mechanisms.

ing this design as an important change, the status of

the design through evolution, and an outline of the

co-simulation ingredients including the discrete-event

model, continuous-time model and the results of run-

ning the co-simulation, are all illustrated. Addition-

ally, engineers are allowed to navigating all detail

changes of the evolution by zooming in the graph.

5 CONCLUSIONS

In this paper, a model management approach for

multi-disciplinary modelling and co-simulation is

proposed. This management approach is used to en-

sure the consistency between different domain mod-

els which can evolve in different rates during a system

development. Based on the approach, a prototype sys-

tem (DESTECS, 2011) in the form of mock-up has

been developed to verify the proposed methods. A

graphical representation of the co-simulation model

evolution process can be generated and shown to the

users, such that the overview of the model develop-

ment process can be inspected.

The idea of auto-detecting changes on text-based

and graph-based models is indicated in this paper, and

its design is future work. Moreover, the complete im-

plementation of this facility, including extensive test-

ing is also future work.

ACKNOWLEDGEMENTS

The research leading to these results has received

funding from the European Community’s Seventh

Framework Programme (FP7/2007-2013) under grant

agreement no. 248134.

REFERENCES

Baharadwaj, A., Choobineh, J., Lo, A., and Shetty, B.

(1992). Model management systems: A survey. In

Annals of Operations Research, volume 38. Springer.

Chao-fan, D. and Qing-Yan, Z. (2009). Research and imple-

mentation of general model management and service

system. In International Conference on Management

and Service Science, MASS ’09. IEEE.

Community, O. (2010). The overture tool website.

http://www.overturetool.org.

Controllab Products (2010). The 20-sim dynamic modelling

tool website. http://www.20sim.com.

DESTECS (2010). DESTECS Project Website. Website.

http://www.destecs.org.

DESTECS (2011). The DESTECS Source-

Forge Project Website. Website.

http://sourceforge.net/projects/destecs.

Kim, S.-K. and Carrington, D. (2006). A pattern-

based model evolution approach. In APSEC’06 XIII

ASIA PACIFIC SOFTWARE ENGINEERING CON-

FERENCE.

Kuppeveld, T. (2007). Model-based redesign of a self-

balancing scooter. Master’s thesis, University of

Twente.

Segway (2007). Segway Personal Transporter. Website.

http://www.segway.nl.

A MODEL MANAGEMENT APPROACH FOR CO-SIMULATION MODEL EVOLUTION

173