Appending Variable-Structure to Modelica Models (WIP)

Transcription

1 Appending Variable-Structure to Modelica Models (WIP) Daniel Gomez Esperon, Alexandra Mehlhase, Thomas Karbe Technische Universität Berlin Ernst-Reuter-Platz 7, Berlin, Germany {gomezesperon, a.mehlhase, ABSTRACT Modeling languages and tools support the development of large simulation models based on components from libraries. In particular model types it is desirable to change components during simulation for performance reasons or to change behavior. Variable-structure models provide a solution with the concept of modes describing sets of systems of equations and transitions between modes. Experimental tools exist, but their reusability is limited due to special languages or the need to implement each mode manually. This paper presents a methodology to append variable-structure simulation behavior to existing models implemented in common component-oriented languages by only defining local component exchanges. The prototypical tool MoVasE implements the proposed methodology and introduces a meta-model to hold the variable-structure information separated from the original models. Based on this information, necessary modes are generated automatically. The variable-structure simulation is executed as a series of conventional simulations. Author Keywords Variable-structure; object-oriented; methodology; Modelica extension; FMI; Eclipse Rich Client Platform. ACM Classification Keywords I.6.5 SIMULATION AND MODELING (Model Development): Modeling methodologies 1. INTRODUCTION Many technical and non-technical systems can be modeled through differential-algebraic equations, which describe the behavior of a system over time under certain conditions. Since reusability is desirable to build large simulation models, it is common practice to partition a model hierarchically into components that describe the behavior of parts of the system. Components can be connected with each other to form more complex components. Those can again be connected resulting in a simulation model built out of components. For instance, an electrical resistor model can be created which defines a type. We can create many resistor components in an electrical circuit model as instances of this type. Each instance has its own state. Further connections with a source or a capacitor may result in a simulation model. SCSC 2015, July 26-29, 2015, Chicago, IL, USA c 2015 Society for Modeling & Simulation International (SCS) Modelica (see is an objectoriented modeling language which allows the modeler to create models based on components from libraries. Simulation models can then be built by instantiating components and by connecting them. Real technical and non-technical systems often consist of different modules and undergo a sequence of different phases. Phases can be described by either one monolithic model covering all phases, often leading to complex systems of equations, or by separate models for each phase. Separate models usually are less complex and therefore beneficial to simulation performance and maintenance. The sequence of phases is often not manually manageable. Separate simulations for each phase are not feasible. With the ability to automatically switch between separate models for different phases during simulation, one can express many desirable effects. Models can change their level of detail, describe different behavior and even add or delete components. Models with such capability are called variable-structure models (VSM). A part of such a model that represents one phase is called mode. Switches between modes are called transitions. A mode switch is triggered by a guard based on the simulation state and requires the initialization of the succeeding mode. Each mode has its individual system of equations. The benefit of variable-structure models has been wellestablished [3, 4], but as of today commercial simulation environments cannot handle them in a sufficient manner. Only prototypes and experimental languages exist. MOSILA with its simulator MOSILAB [6] uses Statecharts-like [1] notations to describe variable-structure behavior. Language SOL [10] and the signal-flow-oriented Ptolemy II [8] are other examples of tools to handle variable-structure models. They are limited in their expressiveness or complexity of the models they can handle. An implementation in the specific language is required instead of reusing existing models or libraries. A language-independent approach to create and simulate variable-structure models is provided by the DySMo framework [2]. In this framework, the simulation of modes in various simulation tools is controlled with a Python script. The different modes of the variable-structure model can be implemented in any simulation environment. Transitions have to be described in a template. Each mode has to be created manually and has to be an executable simulation model. In the assumable case where behavior changes are necessary in

2 a few components only, the change affects a small part of the model only. Two nearly identical models have to be implemented as simulation-ready modes. The overhead of manually copied code is high and error-prone. Maintainability in terms of modifications in the unchanged part of each mode is reduced. In this paper, we pick up the idea of DySMo to implement and simulate modes in established languages. We introduce a new methodology to create necessary modes automatically by appending variable-structure behavior to existing simulation models based on component exchanges. Chapter 2 briefly introduces main challenges and solutions that occur when components are exchanged during simulation with focus on Modelica models. Chapter 3 describes the methodology, which uses a meta-model represented graphically [1, 5, 9] to describe the variable-structure behavior on the highest level. The methodology is explained with a simple RLC resonator example. In seven steps the process in terms of notation and meaning for a VSM is described. A short insight into background processes is given that enables a variable-structure simulation. In Chapter 4 we present the prototype MoVasE that implements this methodology based on Modelica and allows the developer to create and simulate variable-structure models graphically. Chapter 5 presents the conclusion and future work. 2. MAIN CHALLENGES IN EXCHANGING COMPONENTS Modelica s potential of creating complex models with the help of libraries is based on object-oriented features like components and hierarchy. Components do not have a fixed signal flow direction. The direction or causality is derived from the composition of components. This acausality improves reusability heavily. To simulate a model, the combination and hierarchical composition of components and their equations need to be flattened and causalized to one monolithic system of equations. The structural information in terms of components is lost. Our approach describes variable-structure simulation behavior at component level and not at equation level. This will lead to a fundamental change of the system of equations. To perform this change in the system of equations, we exchange components at the highest level and flatten and causalize later. When a component is exchanged with one of another type, the new component has to be adapted to its context in the hierarchical composition. Thus, the interfaces need to be the same. One way to handle this is inheritance. Our approach does not require inheritance between exchanging component types. With mappings we provide possibilities to handle cases where adapting is required. Considering the high level aspects of simulation models in general, initialization is a main challenge for a meaningful simulation [7]. When a VSM changes its mode and therefore its system of equations, another initialization for the new mode has to be executed. With this initialization, a continuous transition from one mode to another has to be ensured. The developer needs to consider some individual aspects of an initialization, but our approach aims to support a continuous transition with deducting default initialization proposals from the model s structure. 3. METHODOLOGY OF APPENDING VARIABLE- STRUCTURE BEHAVIOR When an existing, executable simulation model could benefit from structure-variability, it should be possible to append the desired behavior without the need for a complete reimplementation or redesign. In addition, only relevant types, e.g. with a different level of detail or behavior, should be provided as reimplementations. A library can be used as source. The development process and level of maintainability with wellestablished tools should remain untouched. Figure 1. Seven steps toward variable-structure behavior The proposed methodology describes how such an executable simulation model, the so-called master-model, can be extended into a variable-structure model, such that the mentioned requirements hold. Figure 1 shows the seven steps of the methodology. Figure 2. RLC resonator Each step will be described using the RLC resonator example shown in Figure 2. Here, r is a component with the type SimpleResistor, l an Inductor and c a Capacitor. The goal is to exchange component r : SimpleResistor with a component of

3 a different type during simulation. Exchanges are described with state diagrams locally and independently for each component that needs to be exchanged. In this example we only exchange one component but more exchanges are possible Parse and Analyze The first step is to parse the master-model and a set of reimplemented types. All models are parsed to an easily manipulable form, the so-called abstract syntax tree (AST). Figure 4. Container of exchangeable resistor types Figure 3. Master-model and reimplementation ASTs (simplified) An extract of relevant elements in the RLC example is shown in Figure 3: Model SimRLC is the executable model inside the master-model. Its components r, l, c use models SimpleResistor, Inductor and Capacitor as types. The Reimplementation provides a more detailed TempResistor model type that is used for the component exchange. The TempResistor has a temperature-dependent resistance while the simple one has a constant resistance. A temperature source could be included into the TempResistor model to investigate the Sim- RLC s temperature-dependent behavior at a critical state Exchangeable Types A container of exchangeable model types has to be defined. Only components from those sets of types will be interchangeable. An inheritance relation or any other relation between these types is not necessary. Figure 4 shows the type container Resistor as a state diagram, marking SimpleResistor and TempResistor as exchangeable types. Each node carries its model type AST representation Transition Types We then define transition types between these model types. A transition type restricts the possible component exchanges and introduces a basic initialization and mapping. Defaults and indicators on necessary initializations and mappings are derived. With the two transition types Temp => Simple and Simple => Temp shown in Figure 4 we can later describe exchanges of components of type SimpleResistor with components of type TempResistor and vice versa with default initializations and mappings. When creating a transition type, we analyze both exchangeable model types AST elements and provide information on how a component of the succeeding type can be adapted and initialized based on the type of the predecessor component. The analysis includes interfaces and the number of variables and parameters. The default case is to map variables with the same name and type and to initialize them with the last value of the variable in the predecessor component. In case of the Resistor type container, this means for the transition Simple => Temp: resistance, current and voltage are proposed to be mapped and initialized directly but the parameter temperature for the TempResistor has to be defined manually. Until this step, there is no change of behavior during simulation. All appended information targets type information and provides re-usability options for following component exchanges. In the next two steps, we introduce exchanges of components by exchange containers built on top of components in the master-model. Transition instances of heredefined transition types will be extended with triggers. These component containers will finally lead to variable-structure behavior. It is important to introduce variable-structure behavior at component level to exchange components of the same type in a different way. Variable-structure preparation is introduced at type level for re-useability Exchangeable Components For each component in the master-model, an exchangeable component container can be introduced. In a container, any type from an associated type container can be used to instantiate a new component that can be used for an exchange during simulation. The component container carries the component s AST element of the master-model while all components inside the container carry their model type s AST element. A state diagram is used to describe the component exchange. During simulation, one component of each container is included in the variable-structure model at a time. One component has to be marked as the initial component that is used for the initial mode. We declare component r : SimpleResistor of model SimRLC as an exchangeable component by introducing the exchangeable components container SimRLC.r in Figure 5. The previously defined type container includes the component s current type SimpleResistor and the alternative type TempResistor. Therefore, it is possible to change the type of component r to TempResistor during simulation.

4 Figure 5. Container of exchangeable resistor components 3.5. Transition Instances We instantiate one of the defined transition types from step 3.3. to declare that a component exchange will happen. The transition instance has to be refined for this exchange with component-specific triggers and initializations. Triggers can be time- or state-based, they can be combined logically. The mapping and initialization is supported by the transition type. They can be adjusted by any function or constant values. In Figure 5 with t1:simple => Temp we instantiate a transition named t1 from type Simple => Temp. A time-based trigger could be after 60 seconds of simulation time or statebased when current reaches one ampere. For initialization we use the default mapping of current and voltage with values from the predecessor component. In this case, we have to parametrize the temperature of the TempResistor manually. The other transition type Temp => Simple is not used in this example. At this point, we have the description for a variable-structure RLC resonator simulation where the resistor will change its simple behavior to a temperature-dependent one Mode Generation The manual part of appending variable-structure is completed. The following steps are executed automatically. In general, each possible combination of one component from each component container and the remains of the mastermodel s AST represents a mode in the VSM simulation. The exchange behavior described locally and independently in component containers is interpreted as a Statechart: each state diagram of a container represents a parallel state while hierarchy of states results from component containers inside a component that is exchanged in another container. We generate a graph of modes. Each mode is a set of components. One component from each component container is combined with the remains of the master-model s AST. Figure 6 indicates the process for a VSM with two component containers with three components each. Transitions between modes are derived from transitions inside component containers. Component containers provide the AST element from the master-model which the exchangeable component has to adapt to. With the mapping provided by the transition instance, a new component AST element can be adapted to the master-model s AST. Each mode carries a complete and simulation-ready AST that will be flattened, causalized and compiled. Figure 6. AST Mode generation For the first mode, all exchangeable components marked as initial will be used to generate the initial mode and the simulation-ready initial AST. All outgoing transitions from these initial components are explored to find new sets of components and to build subsequent modes and ASTs. Transitions between components are reused as transitions between modes. For each subsequent mode, the procedure is repeated. Loops are recognized and can be handled. For each generated mode, the AST is compiled the classic, non-structure-variable way to a Functional Mock-up Interface (FMI) package (see with solver included. In the RLC circuit example, we only defined one component container with two components and one transition inside. The two modes and a single transition in Figure 7 are generated. Figure 7. Generated modes 3.7. Variable-Structure Simulation The variable-structure simulation is realized by a sequence of classic, non-variable-structure FMI mode simulations. It starts with the initial mode and its initialization. During simulation of a mode, triggers from outgoing transitions are checked and the simulation is terminated when a condition is met. Results are stored and with help of the transition instances the subsequent mode is found and its initialization is executed. The subsequent mode is then simulated the same way until the stop time or a termination transition is reached. The mode generation and simulation are not supposed to be highly efficient, it is more a proof of the VSM design in the steps before.

5 An interface defines the communication to the meta-model layer. Language-dependent AST elements like components, model types and variables are encapsulated in meta-model objects. It is possible to plugin other language layers with parsers and compilers, as long as they are objected-oriented or a mapping to the meta-model can be found. To simulate VSMs of other languages, their language plug-in has to provide a possibility to compile models to the FMI standard. Figure 8. MoVasE - navigator and editor for component exchanges. 4. PROTOTYPE MOVASE - MODELICA VARIABLE- STRUCTURE EDITOR The MoVasE prototype provides a platform to research variable-structure model design. The tool assists the developer in appending variable-structure behavior to an existing component-based model according to the proposed methodology. It provides support to define sound transitions and to create executable modes which can be compiled to FMIcompliant models. The simulation is performed and controlled as a sequence of FMI mode simulations Technical Background The application consists of three layers: the user interface layer, the meta-model layer and the language layer. The main platform is the Java Eclipse 4 Rich Client Platform (see which supports separation and modularity with its plugin structure. The user interface layer consists of elements from the Standard Widget Toolkit (see Piccolo2D (see for state diagram visualizations and SWT XY Graph (see for result plots. The meta-model is designed with the Eclipse Modeling Framework (see to hold variable-structure information. Main information is the so-called Variable-Structure-Extension that consists of exchangeable type- and component-information such as mappings, initializations and triggers. Based on this information, the mode graph is derived and builds other key data in the model. The meta-model is coupled loosely with the language layer. All analysis algorithms work on the meta-model to be independent from a language. The language layer has to provide a parser, an AST representation with manipulation operations and FMI compilation capabilities. At this stage of development, the only available language layer plugin makes use of the open source JModelica (see platform as parser and compiler. For this reason, the prototype is limited to Modelica models at the moment. All AST manipulation operations are implemented manually as an addition to the JModelica features. javafmi (see serves as an interface to the FMI models and enables full simulation control directly in the application. The loose coupling of the language-layer is realized with Eclipse s plug-in architecture. MoVasE Main Plugin Meta-Model Layer Language Layer LOC Classes Methods Table 1. Metrics of hand-written code in MoVasE. Table 1 shows metrics for the MoVasE tool. The total lines of code (LOC), classes and methods give an impression of the complexity of the program. Used frameworks are not included in the statistics. The meta-model layer code is generated based on the 38 meta-model classes and their relations. Analysis algorithms are implemented in the main plugin Implementation of the Methodology Steps of the methodology are guided with the help of wizards. Each step produces an artifact which has dependencies on its predecessors. Each artifact can have several successors to provide different development branches. For example, based on one set of imported models, different type and component containers can be designed and simulated independently. Each artifact has its own editor. Figure 8 shows the project-based navigator on the left-hand side (section 1) with all artifacts and editors as tabs on the right-hand side (section 2). The visible editor represents the RLC circuit example in step 5 with its component container for an exchange of component resistor of type SimpleResistor with a component of type TempResistor. In Section 2.a the associated type container Resistor is visualized. Based on this container, the component SimpleResistor resistor from section 2.b can be dragged and dropped to the state diagram area 2.c to create a component container. A transition between the resistor component of type SimpleResistor to a component with type TempResistor is introduced. Details of each transition instance have to be described in tab Component Transitions in section 2.d. Mappings and initializations can be adjusted and at least one trigger has to be defined. Analyses in the background of each editing step provide hints on the soundness. Simulation results can be plotted and exported. 5. CONCLUSION, LIMITATIONS AND FUTURE WORK The methodology opens a way to improve existing simulation models with appending variable-structure features. A migration to a special language or an extension of a language is not necessary. The power of established languages is preserved while the complexity of variable-structure models in terms of the amount of modes and transitions is increased. The master-model is referenced and the variable-structure information appended. A change in the master-model would

6 affect all modes. The automatic mode generation distributes this change to all modes automatically. Appended variablestructure information remains untouched. Maintainability of the master-model is preserved. The prototypical tool MoVasE provides an experimental platform in which the meta-model and analysis algorithms can be developed. It can handle many type and component containers as well as state diagram descriptions of component exchanges much greater than shown in the RLC circuit example. The number of generated modes exceeds the amount of manually creatable modes easily. With transition types and their default mappings and initializations the effort to create transitions between components is reduced. This helps to automatically produce sound modes and transitions which are needed for a variable-structure simulation. A variable-structure simulation can be controlled and the result can be visualized. With one mode and different transitions to itself the methodology can be used to find parameter and initialization values. Although the platform is in an early stage, we could show that all steps of the methodology are applicable in a seamless way. The compilation to FMI and simulation is a convenient way to control the simulation of modes directly in Java. It is slow in comparison to the simulation of the model directly in the tool it was designed with. It is not the intention to provide a highperformance simulation environment, but rather to provide an investigation platform for VSM design. For efficient simulation, the mode generation should be delegated completely to a variable-structure compiler and simulator to handle the generation of different systems of equations and changes in a more efficient way. The meta-model provides a set of information such a compiler has to deal with. The methodology and the meta-model are designed to be used for different kinds of object-oriented and similar languages. To prove this, one of the next steps could be the import of Simulink (see models into the MoVasE tool with an additional language layer. One mode has to be described with one language layer. But modes based on different language layers could be combined because of the FMI compilation. More complex, parallel and hierarchic transitions in different component containers will be investigated. Triggers will be analyzed and evaluated before the simulations starts with the help of a lexical analyzer to detect simultaneous changes of components, conflicts or non-determinism. As a result, the generated mode graph in step 6 can be optimized to reduce the amount of generated modes and mode switches during simulation. Neighboring modes could differ in more than one component to handle the exchange of more than one component at once. Resulting variations of the initial model could be used for parallel simulation to identify suitable modes for a simulation period. Tests for the expected variable-structure behavior will be investigated to support the sound definition of triggers and transitions. The methodology could provide indications to extend existing libraries with reimplementations in order to provide easy-tohandle variable-structure types. An output of the prototype tool might also be a scalable notation for variable-structure models. REFERENCES 1. Harel, D. Statecharts: A visual formalism for complex systems. Science of computer programming 8, 3 (1987), Mehlhase, A. A Python framework to create and simulate models with variable structure in common simulation environments. Mathematical and Computer Modelling of Dynamical Systems 20, 6 (2013), Mehlhase, A., Gomez Esperon, D., Bergmann, J., and Merkle, M. An example of beneficial use of variable-structure modeling to enhance an existing rocket model. In Proc. of the 10th International Modelica Conference, Linköping University Electronic Press (2014), Nilsson, H., Peterson, J., and Hudak, P. Functional Hybrid Modeling from an Object-Oriented Perspective. In Proc. of the 1st International Workshop on Equation-Based Object-Oriented Languages and Tools, Springer-Verlag (2007), Nytsch-Geusen, C. The use of the UML within the modelling process of Modelica-models. In Proc. of the 1st International Workshop on Equation-Based Object-Oriented Languages and Tools, Springer-Verlag (2007), Nytsch-Geusen, C., Ernst, T., Nordwig, A., Schneider, P., Schwarz, P., Vetter, M., Wittwer, C., Holm, A., Nouidui, T., Leopold, J., Schmidt, G., Doll, U., and Mattes, A. MOSILAB: Development of a Modelica based generic simulation tool supporting model structural dynamics. In Proc. of the 4th International Modelica Conference, The Modelica Association (2005), Pantelides, C. C. The consistent initialization of differential-algebraic systems. SIAM Journal on Scientific and Statistical Computing 9, 2 (1988), Ptolemaeus, C., Ed. System Design, Modeling, and Simulation using Ptolemy II. Ptolemy.org, Schamai, W., Fritzson, P., Paredis, C., and Pop, A. Towards Unified System Modeling and Simulation with ModelicaML: Modeling of Executable Behavior Using Graphical Notations. In Proc. of the 7th International Modelica Conference, Linköping University Electronic Press (2009), Zimmer, D. Equation-based modeling of variable-structure systems. PhD thesis, Swiss Federal Institute of Technology, Zürich, 2010.