=Paper=
{{Paper
|id=Vol-2019/flexmde_7
|storemode=property
|title=Towards Agile Model-based Systems Engineering
|pdfUrl=https://ceur-ws.org/Vol-2019/flexmde_7.pdf
|volume=Vol-2019
|authors=Joachim Denil,Rick Salay,Chris Paredis,Hans Vangheluwe
|dblpUrl=https://dblp.org/rec/conf/models/DenilSPV17
}}
==Towards Agile Model-based Systems Engineering==
https://ceur-ws.org/Vol-2019/flexmde_7.pdf
Towards Agile Model-Based Systems Engineering
Joachim Denil∗† , Rick Salay‡ , Chris Paredis§ , Hans Vangheluwe∗†¶
∗ University of Antwerp, Belgium
Email: {Joachim.Denil,Hans.Vangheluwe}@uantwerpen.be
† Flanders Make, Belgium
‡ University of Toronto, Canada
Email: rsalay@cs.toronto.edu
§ Georgia Institute of Technology, USA
Email: Chris.Paredis@me.gatech.edu
¶ Mcgill University,Canada
Email:hv@cs.mcgill.ca
Abstract—Engineering organisations following a traditional de- There is evidence that agile methods are more successful
velopment process often suffer from under-specified requirements than traditional methods. For example, a recent quantitative
and from poor responsiveness to changes in those requirements analysis of development projects showed that agile methods
during the course of a project. Furthermore, these organizations
need to deliver highly dependable products and decrease time-to- provide a statistically significant benefit to project success
market. In the software engineering community, Agile methods factors of efficiency, stakeholder satisfaction and perception of
have been proposed to address similar issues. Pilot projects project performance [3]. Unfortunately, agile software meth-
that apply agile approaches in Cyber-Physical Systems (CPS) ods cannot be transposed to the engineering context with-
engineering have reported some success. This position paper out adaptation. For example, having a working system (i.e.,
studies the challenges faced when adopting an agile process
to design CPS. These challenges are broken down into their corresponding to “compiled, working code” in the software
essential components and solutions are proposed, both pertaining realm) amenable to end-user evaluation, after each iteration, is
to model/simulation management and to processes. typically infeasible. A possible alternative is to have working
models of the system [4]. ‘Working model” means that stake-
I. I NTRODUCTION holders must be able to meaningfully evaluate the system by
model-checking, (co-)simulating, etc. the model. Clearly, this
With today’s fast pace of change and increasingly complex can only be achieved with appropriate tool support.
requirements, new ways must be found to engineer systems In this position paper, we identify the ways in which agile
more quickly and with higher integrity. Traditional waterfall- methods must be adapted to fit the model-based engineering of
like life-cycles such as the “V” process suffer from poor Cyber-physical Systems (CPS) context and describe the meth-
responsiveness to changes in the requirements of the system ods, techniques and tools needed to support these adaptations.
under construction. These changes are a consequence of Section II presents the state of the art in agile engineer-
legislative changes, changes in the market demand of the ing. Most of the literature on agility in the mechatronic,
customer, and company policy. Often, changes stem from software-intensive and CPS domains re-use the principles of
underspecified or even missing requirements. Rigid processes, agile software development with little change. (and hence,
such as the “V” process, freeze the requirements of the system a software focus remains). We reflect on the original needs
throughout the design cycle. Consequently, wrong assumptions for agility: to reduce the risk of building a wrong system.
or underspecified requirements are discovered very late in Section III, identifies the main challenges of agile CPS For
the development cycle, for example, only once a full system each of these challenges, section IV investigates appropriate
prototype is demonstrated to the customer. This results in model/simulation management and process solutions. Figure 1
costly redesign. serves as a map for the relationships between challenges and
In response to similar problems, the software engineering solutions described in this paper. Finally, section V concludes.
community has introduced more lightweight development or
iterative methods such as Scrum [1]. These development meth- II. R ELATED W ORK
ods are now commonly referred to as Agile. The principles and Woodcock adapted the agile manifesto for systems engi-
concerns for Agile practices in software engineering were pub- neering [4]. Recently, Bruce Douglass [5] adaptated the IBM
lished in the Manifesto for Agile Software Development [2]. Harmony systems engineering methodology to be more agile.
The main principles of agility according to these authors are a In his approach, models replace code as the artifact produced
preference for: (a) individuals and interactions over processes in an iteration and must be “executable.” Klein and Reinhart
and tools, (b) working software over comprehensive documen- provide mechatronic development companies with approaches
tation, (c) customer collaboration over contract negotiation, to incorporate agile methods and techniques in their current
and (d) responding to change over following a plan. processes [6]. Two specific processes, a vertical and horizontal
High risk Sub-Optimal Certication Needs
Time-to-Market (e.g. Safety
Standards)
Unknown Changing
Requirements Requirements
Rigid
Show Full Processes
System to Customer
at Regular Intervals
Legend
(Non-fixed In Conict:
Challenge Current Design Process:
Length)
Late and/or Partial Rigid <> Flexible
Sprints (iterations)
Possible Integration Processes
Flexible Processes
Solution
Early System- Process Incremental
level Optimisation Safety
Evaluation
Traceability
Too Early Heterogeneity Heterogeneity
Need for Heterogeneity Heterogeneity in Model COTS Models
Commitment to in Model
IPProtection in Views inAbstraction Construction/ and Libraries
Design Decisions Components
EvaluationTime
Inconsistencies
in Design WrongAssumptions
in Composite/
Component Models
Transformation (Incremental) Cross- Model
Partial Co- Upper
to a Common Consistency functional Automatic Validity
Models Simulation Ontologies
Formalism Management Teams Abstraction Contracts Frames
Fig. 1. Overview of challenges and possible solutions
process, combine techniques from agile with the traditional III. C HALLENGES OF AGILE CPS DESIGN
gated processes in mechatronic engineering.
In the following, we identify a number of challenges in
In 2014, Tetra-pack undertook a pilot project to test the use the design of Cyber-Physical Systems. CPS are characterised
of agile methods in engineering [7]. They combined a Scrum- by a tight integration and coordination between physical,
like process during the development phase with a traditional V computational and network components [10]. CPS can be seen
waterfall process for full system verification before releasing to as the natural evolution of software intensive and mechatronic
the customer. A key motivation for trying out an agile method systems to a higher complexity. Application domains include
was to avoid losing customers due to delays and be able to medical devices, advanced automotive systems, aeronautics,
respond more quickly to new trends. Overall, they observed etc.
better employee motivation and better work efficiency in the a) High Risk in Engineering: : Engineers want to reduce
project. the risk of failure in both the product or the project [11]. A
product fails because of problems such as reliability issues or
[8] summarizes several studies on the use of agile methods
working with wrong, incomplete, or changing requirements.
in aircraft systems integration at Johns Hopkins. The Cube-
The risk of changes in the requirements needs to be managed
Sat multi-mission bus demonstrator is engineered using five
and is the main driver to include agile principles into a design
engineering teams. They experienced that co-located teams
process.
reduced communication complexity. Incremental test methods
b) Dependability Challenges: CPS must be dependable.
allowed them to find problems early. [9] reports on three
Dependability is a measure of the availability, reliability,
case studies where agility is introduced in a non-software
durability, safety and security of a system. Dedicated standards
environment at three different companies: Marel GRB, Saab,
address dependability in different domains. A well known
and Andritz Hydro. The experience shows that it is possible
example is the ISO26262 standard addressing the functional
to use agile principles for electro-mechanical systems design.
safety of an automotive system. Functional safety standards
These approaches adapt agile processes without any extra impose a rigorous process with different phases on the product
methods, techniques and tool support. In this paper we identify developers.
several enabling techniques to help engineers being more agile c) Sub-optimal Time To Market: Time to market (TTM)
in the design of CPS. is closely related to value creation as profit earned by a product
not only depends on engineering time and production cost but customer to identify wrong or unknown requirements early
also on its launch date [12]. Most engineers do not take this in the design process. This is in contrast with the current
into account when designing a system. It should be possible design processes in the CPS domain. Mostly, engineers use
to optimize a design process to take the full product value, rigid processes that only integrate the system very late in
including TTM, into account. the design cycle. System engineers introduce some process
d) Heterogeneity Challenges: Several heterogeneity steps to partially mend this issue. An example of this are the
challenges can be identified: (a) Due to the tight integration construction of (physical) system prototypes. However, build-
between different physical, computation and communication ing such a prototype is a costly and time-consuming activity.
components, the design of CPS is heterogeneous as well. The Furthermore, even when standardised physical test benches
engineers, as experts in their own domain, work in domain- are available, system evaluation can be extremely expensive
specific “silos”, and may have a different vocabulary. It is and time-consuming while not providing the needed insights
important that these different domain experts can communi- into the unknown requirements and wrong assumptions [17].
cate and understand the cross-functional design issues, and A translations of this principle for systems engineering is
understand the interest of the other stakeholders in the system early full system-level analysis. The analysis serves the same
under design [13]. (b) The complexity of CPS also leads need as the “working software” but can be completely virtual
to the use of multiple views on the system under design. using an evaluatable model. Because the evaluation occurs at
Multiple views address different concerns such as safety, system-level, the system level properties are being analysed.
energy consumption, desired function, etc. This results in ‘Evaluatable model” means that stakeholders must be able
sometimes unknown relations and dependencies between the to meaningfully evaluate the system by model-checking, (co-
different views [14]. (c) The problem is further exacerbated )simulating, etc. the model [4]. Appropriate tool support is
by the use of different modelling formalisms. Each engineer required to achieve this.
uses a dedicated set of most appropriate design languages, e.g. A particular challenge is dealing with the different types of
Simulink diagrams for control engineering, 3D CAD models heterogeneity during the design of CPS. Below we describe
for geometric engineering, etc. The dependencies between multiple of such possible solutions that deal with system-level
the different silos and views are rooted in dependencies and evaluation and heterogeneity.
overlaps in the semantic domain of the models [15], [16]. b) (Non-)fixed-length Sprints: Having “Evaluatable
(d) Another dimension of the heterogeneity is a consequence models” early on in the process is only one part of the
of the difference in time to create or evaluate a model. 3D agile solution. The other part is having these evaluations at
models are much more labour-intensive to create compared regular intervals in the design process of the CPS. Agile
to a 1D model of the physics. Furthermore, computational software engineering introduces the concept of a fixed length
fluid dynamics simulations are much more computationally “sprint”. Within a sprint, a system fully realizing a set of
demanding compared to the simulation of a causal plant model selected requirements is constructed that can be evaluated by
in Simulink. (e) Finally, there can also be heterogeneity in the different stake-holders.
the levels of abstraction between the different artifacts. When Requirements are chosen for inclusion in a sprint, based
building a system, certain parts of the system may require more on risk analysis. High-risk (critical to system operation, high
detailed models than others, to attain a desired level of fidelity. uncertainty, low confidence, . . . ) requirements are best in-
In case components are sourced from external suppliers, the cluded as early as possible. Hidden and unknown dependencies
level of model detail may be imposed extrinsically. may occur between different requirements. It is important
e) Intellectual Property: Internal and external suppliers that engineers have the methods, techniques and tools at
have a vested interest in the knowledge they build up through their disposal to chart these dependencies and the associated
defining models of their components. Therefore it is important risks. Two derived challenges arise. (a) Iteratively creating the
that methods, techniques and tools are able to protect this intel- system, without an up-front choice of requirements to include
lectual property of the different stakeholders. Such protection in each sprint, conflicts with the rigorous processes that
may impede certain kinds of full system evaluation however. safety and other dependability standards prescribe. A possible
solution is to adhere to the safety process in the final sprint,
IV. P OSSIBLE S OLUTIONS linking all information using traceability, or, incrementally
In this section we look at the possible scientific solutions building the safety case(see later). (b) The time-heterogeneity
for the presented challenges. Figure 1 serves as a map for the in creating and evaluating parts of the system has to be taken
relationships between the challenges and solutions. into account during requirement selection and risk analysis.
a) Show Working System to Customer at Regular In- Process optimisation might provide guidance (see later).
tervals - Early System-Level Evaluation: To reduce the risk c) Co-Simulation: CPS are designed using a multi-
of building a system with wrong assumptions or having to tude of languages and tools. The agile approach requires
start over when the requirements change during the design that these heterogeneous models are meaningfully combined
process, the agile software community introduced the prin- for full-system evaluation at the end of every sprint. Co-
ciple of continuous delivery. Working software is frequently simulation [18] is a technique that allows coupling of black-
produced and evaluated by the customer. This allows the box simulation units that do not expose all information in
the models. This protects intellectual property of internal as verification [26] and model transformation [28].The above
and external component suppliers. Co-simulation is an IP techniques can be transposed to the architectural models used
protecting technique that allows coupling of black-box simu- in current engineering approaches. Extending the partiality
lation units. E.g. the Functional Mock-up Interface (FMI) is a to other formalisms remains a challenge. E.g. in a model
standard for coupling continuous-time simulation components. of the physics, a component parameter may be replaced by
However, FMI does not specify how to simulate the different a distribution, resulting in a stochastic differential equation.
mock-up units together. A so-called master algorithm needs All operations, such as simulation and transformation should
to be used. A master algorithm reasons about the coordi- be applied to a collection of models rather than to a single
nation/communication between the different FMUs and how model. This can drastically affect performance. Furthermore,
to solve emerging global model artefacts such as algebraic the trade-off between partial models and the implied compu-
loops. Generic co-simulation algorithms exist [19] as well as tational overhead should be supported by guidelines.
techniques to generate an optimised orchestration [20]. Cou- f) Upper Ontologies: In a multi-view, multi-disciplinary
pling discrete-event models to continuous-time models is still context, it is crucial that engineers are aware of when they
needed for FMI. Different solutions have been proposed [21], reason about identical concepts, even when they use their
[22]. An overview of different methods and techniques for own, domain-specific terminology and formalisms, (Upper)
co-simulation can be found in [18]. ontologies allow for the high-level classification of real-world
There are a number of challenges for co-simulation, e.g. entities as well as of relations between these entities. New
for proving the correctness of a co-simulation scenario or knowledge can be inferred by reasoning over these ontologies.
combining units with different levels of detail. A scenario g) Incremental Consistency Management: Because of
can be correct in the computer science sense, the correct data multi-view modelling approaches in the design of CPS, both
types are coupled, etc. In the mathematical and numerical syntactic and semantic overlaps occur. After each sprint, it is
sense, correct numerical integration steps are selected. And important to end up with a consistent system model. Therefore,
finally, adhering to the laws of physics, e.g. energy and mo- dedicated consistency management approaches are needed.
mentum are conserved. An example is the formal verification This can be supported by having a dedicated role in the team to
approach in [23]. A major challenge is dealing with multi- manage inconsistencies. Model inconsistency is a well known
abstraction/purpose/precision components: how can we take problem in model-oriented approaches. Many solutions act on
advantage of an FMU that contains different abstraction levels the syntactic level, e.g. [29] On the semantic level, Qamar
in the black-box. creates a dependency modelling language to map the semantic
d) Transform to a Common Formalism: Another tech- dependencies between different artifacts in a project [30].
nique to couple heterogeneous models, is to transform all Herzig et al. create a Baysian inference mechanism to identify
components to a common formalism [24] which support model possible semantic overlaps in models [31]. Vanherpen et al.
evaluation. To bridge to cognitive gap between the original reason with upper ontologies to map the different semantic
design model and the automatically generated model in the overlaps in a project [16]. In an agile context, lightweight
common formalism, back-annotation is required. Vangheluwe solutions to consistency management are needed. The above
identified DEVS as a common denominator for hybrid mod- methods can be incremental and combined with learning
elling [25]. Another approach is to create a combination of approaches and ontology-based reasoning.
multiple formalisms. This implies, as with co-simulation, that h) Cross-functional Teams: Traditional engineering pro-
the coordination between the different formalisms is specified. cesses put individual engineering disciplines in distinct silos
Fragment-based composition of different languages at both the with communication structured along well-defined hand-offs.
syntactic and semantic level remains a challenge. This discourages and interferes with interactions across disci-
e) Partial Modelling: In the agile model based systems ples that could help detect and resolve conflicts early. An agile
engineering approach, we advocate early and regular full- approach uses cross-functional teams to leverage the different
system evaluation. However, to allow for simulation and skill sets and perspectives effectively during development.
analysis of early models, one may need to fix certain design This works well in software development, as the different
choices while the most valuable action would be to defer this skills are closely aligned. Code is after all the common
choice. A possible solution is to explicitly model the deferment semantic domain. The challenge to adopting this approach in
or partiality of the design choice. This requires reasoning, engineering is that the languages, tools and cultures of the
not about a single design, but about a set of designs. This different disciplines are quite distinct making collaboration
is called Partial Modeling [26] or Models with Holes. In difficult, even if the participants are all in the same room.
[27], the authors formalise partial models that support four Some form of mediation is required.
different annotations:(a) May partiality: the element may exist, i) Automatic Abstraction: When combining component
(b) Abs partiality: we do not know whether it is a set of models to arrive at an evaluatable full-system model, there are
elements, (c) Var partiality: whether the element should be likely to be mismatches in the abstraction levels of the different
merged with another element and (d) OW partiality referring components. When evaluating such heterogeneous systems,
to the (in-)completeness of the model. Different operations automatic abstraction techniques can help in creating a finite
needed for design have been “lifted” to partial models, such model that can be checked using formal verification techniques
such as [32]. Commonly, some of the component models upper ontologies (see earlier) to meaningfully reason about the
require costly computation as they can be used for evaluating content of contracts between different domains [37]. Exam-
many different properties. In certain cases, for example during ples of contracts between control engineers and deployment
design-space exploration, one is only interested in a subset engineers can be found in [38]. Contracts are desirable as
of these properties. Model abstraction, surrogate modelling, they simplify integration and verification. They might however
or meta-modelling (not to be confused with the language introduce too much rigidity in the development process as they
engineering term) are techniques to derive a simplified model need to be formalised and negotiated. A challenge is thus to
from a more complex model while trying to maintain fidelity employ contracts without compromising agility.
with respect to a subset of the properties. l) Process Optimisation: To allow for shorter time-to-
j) Validity Frames: To rapidly create virtual prototypes market, processes should be optimised, for example perform-
of a system, designers often use components from model ing independent tasks concurrently. This optimisation should
libraries or of-the-shelf models that are provided by the take (in)consistency and the trade-off between value and
supplier of the component. This virtual systems composition optimised product into account. Queueing Network process
mimics its physical-world assembly counter-part. The topic of performance can help to create optimal processes, by means
physical component reuse for system design is well known of process simulation, similar to [39]. The calibration of these
in engineering. Component catalogues shows all the proper- models requires historical data.
ties and usage constraints of each component, enabling the m) Incremental Safety: A way to allow for a more agile
engineer to make an informed decision. Reuse of models is process with safety support is the incremental creation of the
treacherous however. During the act of modelling, the modeller safety goals and corresponding cases. Incrementally creating
makes a conscious choice about which properties are taken this should deliver evidence after each sprint that the new
into account and which properties or phenomena are neglected. safety goals are verified, Furthermore, it should also provide
This depends on the modellers intent and what is of interest at evidence that the safety cases corresponding to previously
that point in the design process. Reuse of a model thus not only selected safety goals are still valid. Kokaly et al. provide
depends on the model itself but also on the specific intents that a model management approach to allow for such reuse of
the modeller had during the design process. Zeigler identified assurance cases when a system evolves [40].
this problem in [33]. He introduced the Experimental Frame n) Traceability: Traceability keeps track of relationships
to model the context in which a model can be observed between all the different artifacts, including requirements,
and experimented with. The experimental frame in Zeigler’s design, tests, etc. during system development. Traceability
book is further defined using three main components. (a) The is needed to create the assurance cases needed for safety
generator describes the allowable inputs to the model, (b) The and other dependability standards. It also gives the end-user
transducer to processes the output coming from the generator feedback within the view/formalism he/she is familiar with.
and the model, e.g. integrates the output or takes the mean. Trace management becomes increasingly important as the
(c) The acceptor accepts or rejects the model. Note that a system design becomes more and more iterative with models
model can have multiple experimental frames and a frame can at different levels of abstraction. Techniques such as impact
be valid for multiple models. Several authors have discussed analysis depend on the availability of traces.
the experimental frame and its relation to the M&S process,
e.g. [34]. The concept of the experimental frame is however V. C ONCLUSIONS
hard to implement, use as a contract for model selection, In this position paper we analysed some of the different
validate or calibrate models. In [35], the authors extended challenges related to reducing the risk of failure in the design
the experimental frames to the more general concept of process of Cyber-Physical Systems: changing and unknown
purpose-drive frames where the validity and calibration frame requirements, dependability of the system, sub-optimal time-
are just two frames that specify the information needed for to-market, heterogeneity and intellectual property. Drawing
meaningful reuse of models and reproducibility of calibration inspiration from successful Agile approaches in software en-
and validation. Reasoning with these frames is still an open gineering, we proposed a scala of scientific solutions and, in
area of research. Furthermore, reusable models libraries have turn, their related challenges.
to be constructed taking these frames into account.
R EFERENCES
k) Contracts: To allow for concurrent design (co-design)
of different parts of a system, interfaces and overlaps in [1] Pete Deemer, Gabrielle Benefield, Craig Larman, and
Bas Vodde. The scrum primer v.1.2. Available at:
the semantic domain such as resource consumption, need to http://goodagile.com/scrumprimer/scrumprimer.pdf [Accessed May
be negotiated. Contract-based approaches in the context of 2017], 2010.
CPS allow a formalisation of such co-design using assume [2] Kent Beck, Mike Beedle, Arie Van Bennekum, Alistair Cockburn, Ward
Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew
and guarantee contracts. Under the assumed conditions, Hunt, Ron Jeffries, et al. The agile manifesto. 2001.
the component promises to fulfill the guaranteed properties. [3] Pedro Serrador and Jeffrey K Pinto. Does agile work? – a quantitative
Benveniste et al. describe the mathematical foundations of analysis of agile project success. International Journal of Project
Management, 33(5):1040–1051, 2015.
refinement, composition and conjunction operators on con- [4] Hzael Woodcock. The agile manifesto reworked for systems engineering.
tracts [36]. Vanherpen et al. extend the contract approach with Technical report, IBM, 2013.
[5] Bruce Powel Douglass. Agile Systems Engineering. Morgan Kaufmann, [24] Pieter J. Mosterman and Hans Vangheluwe. Guest editorial: Special
2015. issue on computer automated multi-paradigm modeling. ACM Trans.
[6] Thorsten P. Klein and Gunther Reinhart. Approaches for Integration Model. Comput. Simul., 12(4):249–255, October 2002.
of Agile Procedures into Mechatronic Engineering of Manufacturing [25] Hans Vangheluwe. Devs as a common denominator for multi-formalism
Systems, pages 225–230. Springer International Publishing, 2014. hybrid systems modelling. In IEEE International Symposium on
[7] Bettina Buchel. How to build an agile beast. Technical report, IMD, Computer-Aided Control System Design (ed. Andras Varga), IEEE
2017. Computer Society Press, Anchorage, Alaska, sept. 2000, pages 129–134,
[8] Robert Carlson and Richard Turner. Review of agile case studies for 2000.
applicability to aircraft systems integration. Procedia Computer Science, [26] Michais Famelis, Rick Salay, and Marsha Chechik. Partial models: To-
16:469–474, 2013. wards modeling and reasoning with uncertainty. In Software Engineering
(ICSE), 2012 34th International Conference on, pages 573–583. IEEE,
[9] Thórdı́s Reynisdóttir. Scrum in mechanical product development: Case
2012.
study of a mechanical product development team using scrum. Technical
[27] Rick Salay, Michalis Famelis, and Marsha Chechik. Language Inde-
report, Chalmers University of Technology, Sweden, 2013.
pendent Refinement Using Partial Modeling, pages 224–239. Springer
[10] Edward A Lee. Cyber physical systems: Design challenges. In 2008 Berlin Heidelberg, Berlin, Heidelberg, 2012.
11th IEEE International Symposium on Object Oriented Real-Time [28] Michalis Famelis, Rick Salay, Alessio Di Sandro, and Marsha Chechik.
Distributed Computing (ISORC), pages 363–369. IEEE, 2008. Transformation of Models Containing Uncertainty, pages 673–689.
[11] Lynne P Cooper. A research agenda to reduce risk in new product Springer Berlin Heidelberg, Berlin, Heidelberg, 2013.
development through knowledge management: a practitioner perspective. [29] Alexander Egyed. Instant consistency checking for the uml. In Pro-
Journal of Engineering and Technology Management, 20(1–2):117 – ceedings of the 28th international conference on Software engineering,
140, 2003. pages 381–390. ACM, 2006.
[12] Benjamin D Lee and Christiaan JJ Paredis. Accounting for the duration [30] Ahsan Qamar. Model and dependency management in mechatronic
of analyses in design process decisions. SAE International Journal of design. PhD thesis, KTH, 2013.
Materials and Manufacturing, 3(2010-01-0908):512–522, 2010. [31] Sebastian JI Herzig and Christiaan JJ Paredis. Bayesian reasoning over
[13] Estelle Frey, Egon Ostrosi, Lionel Roucoules, and Samuel Gomes. models. In MoDeVVa@MoDELS, pages 69–78, 2014.
Multi-domain product modelling: from requirements to CAD and sim- [32] Robert A Thacker, Kevin R Jones, Chris J Myers, and Hao Zheng.
ulation tools. In International Conference on Engineering Design, Automatic abstraction for verification of cyber-physical systems. In
ICED’09, 2009. International Conference on Cyber-Physical Systems, pages 12–21.
[14] Ahsan Qamar, Christiaan JJ Paredis, Jan Wikander, and Carl Dur- ACM, 2010.
ing. Dependency modeling and model management in mechatronic [33] B. P. Zeigler, H. Praehofer, and T. G. Kim. Theory of Modelling
design. Journal of Computing and Information Science in Engineering, and Simulation, Integrating Discrete Event and Continuous Complex
12(4):041009, 2012. Dynamic Systems. Academic Press, 2 edition, 2000.
[15] Magnus Persson, Martin Törngren, Ahsan Qamar, Jonas Westman, [34] Mamadou K. Traoré and Alexandre Muzy. Capturing the dual relation-
Matthias Biehl, Stavros Tripakis, Hans Vangheluwe, and Joachim Denil. ship between simulation models and their context. Simulation Modelling
A characterization of integrated multi-view modeling in the context of Practice and Theory, 14(2):126–142, 2006.
embedded and cyber-physical systems. In Proceedings of the Eleventh [35] Joachim Denil, Stefan Klikovits, Pieter Mosterman, Antonio Vallecillo,
ACM International Conference on Embedded Software, page 10. IEEE and Hans Vangheluwe. The experimental model and the validity frame
Press, 2013. in M&S. In Proceedings of the Symposium on Theory of Modelling and
[16] Ken Vanherpen, Joachim Denil, István Dávid, Paul De Meulenaere, Simulation, 2017.
Pieter J Mosterman, Martin Torngren, Ahsan Qamar, and Hans [36] Albert Benveniste, Benoit Caillaud, Dejan Nickovic, Roberto Passerone,
Vangheluwe. Ontological reasoning for consistency in the design Jean-Baptiste Raclet, Philipp Reinkemeier, Alberto Sangiovanni-
of cyber-physical systems. In Cyber-Physical Production Systems, Vincentelli, Werner Damm, Thomas Henzinger, and Kim G. Larsen.
Workshop on, pages 1–8. IEEE, 2016. Contracts for System Design. Research Report RR-8147, INRIA,
November 2012.
[17] N. Pedersen, K. Lausdahl, E. Sanchez, P. Larsen, and J. Madsen. [37] Ken Vanherpen, Joachim Denil, Paul De Meulenaere, and Hans
Distributed co-simulation of embedded control software with exhaust Vangheluwe. Ontological reasoning as an enabler of contract-based co-
gas recirculation water handling system using into-cps. Technical report, design. In International Workshop on Design, Modeling, and Evaluation
under review, 2017. of Cyber Physical Systems, pages 101–115. Springer, 2016.
[18] Cláudio Gomes, Casper Thule, David Broman, Peter Gorm Larsen, [38] Patricia Derler, Edward A Lee, Martin Törngren, and Stavros Tripakis.
and Hans Vangheluwe. Co-simulation: State of the art. CoRR, Cyber-physical system design contracts. In Cyber-Physical Systems
abs/1702.00686, 2017. (ICCPS), International Conference on, pages 109–118. IEEE, 2013.
[19] Jens Bastian, Christop Clauß, Susann Wolf, and Peter Schneider. Master [39] István Dávid, Joachim Denil, Klaas Gadeyne, and Hans Vangheluwe.
for co-simulation using fmi. In Proceedings of the 8th International Engineering process transformation to manage (in)consistency. In
Modelica Conference; March 20th-22nd; Technical Univeristy; Dresden; COMMitMDE), pages 7–16, 2016.
Germany, number 63, pages 115–120. Linköping University Electronic [40] Sahar Kokaly, Rick Salay, Valentin Cassano, Tom Maibaum, and Marsha
Press, 2011. Chechik. A Model Management Approach for Assurance Case Reuse
[20] Bert Van Acker, Joachim Denil, Hans Vangheluwe, and Paul De Meu- due to System Evolution. In Proc. of MODELS’16, 2016.
lenaere. Generation of an optimised master algorithm for fmi co-
simulation. In Proceedings of the Symposium on Theory of Modeling
& Simulation: DEVS Integrative M&S Symposium, DEVS ’15, pages
205–212. SCS, 2015.
[21] David Broman, Christopher Brooks, Lev Greenberg, Edward A Lee,
Michael Masin, Stavros Tripakis, and Michael Wetter. Determinate
composition of fmus for co-simulation. In Proc. 11th ACM International
Conference on Embedded Software, page 2. IEEE, 2013.
[22] Joachim Denil, Bart Meyers, Paul De Meulenaere, and Hans
Vangheluwe. Explicit semantic adaptation of hybrid formalisms for fmi
co-simulation. In Proceedings of the Symposium on Theory of Modeling
& Simulation: DEVS Integrative M&S Symposium, DEVS ’15, pages
99–106. SCS, 2015.
[23] Luiza Gheorghe, Faouzi Bouchhima, Gabriela Nicolescu, and Hanifa
Boucheneb. A formalization of global simulation models for contin-
uous/discrete systems. In Proceedings of the 2007 Summer Computer
Simulation Conference, pages 559–566. SCS, 2007.