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.