MODELITH: A FRAMEWORK ENABLING TOOL-INDEPENDENT MODELLING AND SIMULATION

Transcription

1 MODELITH: A FRAMEWORK ENABLING TOOL-INDEPENDENT MODELLING AND SIMULATION Jonas Larsson Björn Johansson Petter Krus Magnus Sethson Mechanical Engineering Systems Department of Mechanical Engineering Linköping University, Sweden jonla@ikpliuse KEYWORDS Differential-algebraic equations, Modelica, numerical solvers, code generators, object-oriented modelling ABSTRACT Several approaches exist for modelling of physical systems, often implemented in a modelling language Due to differences in modelling approaches, it is a complicated procedure to interchange information between different modelling languages, documents or applications This puts a constraint on what the users can do in terms of custom simulators and on what simulation tools they can combine In order to overcome this situation, a framework named Modelith is presented in this paper that defines the translation procedure from modelling language to executable model in a number of steps This enables the user to move from a tool-centric to a model-centric view where the models are independent of the simulation tools An implementation of the framework is presented using XML-based technologies for information management As an example, it is shown how this implementation can be used to translate a subset of the modelling language Modelica into components for the simulation tool Hopsan INTRODUCTION Today, mature languages exist for declaring simulation models of physical systems within the technical, biological and chemical domains Some of these languages are Modelica (Elmqvist et al 1999), Ascend (Piela et al 1991) and VHDL-AMS (IEEE 1999) Support for them is given by a number of tools for model creation, editing and numerical simulation The languages have become increasingly powerful with support for non-causal models, object-oriented concepts like inheritance and with possibilities to describe both continuous and discrete phenomena The increasing flora of languages and desires to interchange information between them might lead to drawbacks in the future engineering process Also the developers of the engineering tools can not possibly oversee and maintain language translators for every possible combination needed As a result, since most users do not have the knowledge nor resources for creating necessary translators, the tool providers dictate what can be done with models written in a certain language If it was easier to transform models into and out from a certain language, the following advantages would be reached The possibility to edit models using different levels of abstraction using custom editors To present models in several ways Some are suitable for experts and others for novice users Models can be translated into programming languages such as C and Java This gives the possibility eg to create code suitable for embedded systems and to create stand-alone simulators Since models can be translated into virtually any desired implementation language, they become portable The portability is necessary, since engineering work is becoming more of a co-operative task They need to be easy to adopt to new engineering tools Models will get easier to maintain for future use, even if a certain tool disappears from the market The models thereby become future proof With a proposed intermediate format the authors trie to solve some of these problems, both in terms of flexibility for future use, easy translator generation and fulfilment of the modelling and simulation requirements The XMLstandard has many of these properties and is also the focus of this paper The ideas are presented as a framework together with an implementation RELATED WORK A similar approach exists, called DS-Block (Otter and Elmqvist 1995), which is a low-level description of models that can contain both implicit and explicit models The difference between DS-Block and the proposed framework is that the DS-block model description is intended mainly as a general format to be accessed by numerical solvers, and not for generation of other model representations Modelling and simulation of the human body using XML as model carrier is done in (Ward et al 2001) and in the CellML language specified by the Bioengineering Institute at the University of Auckland Also concepts for modelling of chemical processes using XML are under progress; see (Murray-Rust et al 2001)

2 THE FRAMEWORK Two steps with clearly defined interfaces can describe the transformation from a declarative modelling language into an executable model: 1 Flattening of model into equations, variables etc and removing the hierarchy in the modelling description 2 Implementation of the equations into a computer language An intermediate model language is defined, as shown in Figure 1 Four types of transformers can be made; the two mentioned above for flattening and conversion/implementation of equations and two for translating languages into and from the intermediate language This makes it possible to combine transformers from different vendors into a chain of language transformers that builds up a language transformation Modelica Transformer Intermediate lang VHDL-AMS Transformer Object-oriented implicit Flattened implicit Flattened explicit Transformers Transformer Transformer The language should be be extendible so that the implementation suggested eg in this paper can be altered without too much work and with backward compatibility TECHNOLOGIES USED FOR THE IMPLEMENTATION The authors chose XML, a standard recommended by the World Wide Web Consortium (W3C), as a base for the intermediate language XML is a standard for representing relational data, and brings text documents to a higher level by introducing a hierarchy where each level contains an identifier, tag, and some text data XML is originally designed for exchange of data over the Internet, why many possibilities to transform XML data are available It is a mark-up language very much like HTML It is lightweight in comparison with eg STEP (ISO 10303) and it supports the definition of schemas (expresses the data model) for validation of the produced documents There exist a large variety of open-source and license-free tools for performing various operations on XML documents and the support for XML will be long lasting due to its fundamental nature This language supports, by itself, most of the demands mentioned above for the intermediate language To illustrate the most fundamental concept to mark up data using XML, the example below shows some XML data Two elements are there, Modelith and model, where model is contained in Modelith The model element has an attribute with the name name and value Spring This vocabulary is used later in the paper Standalone application Java Matlab/Simulink S-function <Modelith> <model name= Spring /> </Modelith> Figure 1 The Framework Consisting of an Intermediate Language and a Number of Transformers The later operations are easier to implement than the earlier ones in the chain To parse a language is not an easy task, even if there are tools providing support for that Often this part requires symbolic math operations To generate target language implementation is an easier task, especially when using XML as intermediate format This is also the most interesting operation for the end user of the implemented framework GENERAL CONSIDERATIONS FOR THE INTERMEDIATE LANGUAGE A number of requirements can be put on the intermediate language These have all been considered in the paper It should be straightforward to transform from and into it The most important features of modern modelling languages should be supported, such as Modelica, but not to such extent that the translation process becomes overly complex It must be easy to validate syntax and relations It should be expressive enough for the purpose of using it as a model repository Figure 2 XML Document Sample XSLT, a standard recommended by W3C, is a technology for transforming XML documents into any text format It does not demand much knowledge in programming but focuses on the transformation operation itself The authors have made use of XSLT to a large extent in the transformers described earlier In the flattening and export transformers, XSLT is the only tool needed These transformers are therefore especially easy to adopt and create for new purposes The operation of converting the equations into calculations is performed using a programming language; in this case Java for portability and for the close relation between Java and XML A symbolic math package is also needed to extend the capabilities of Java We have used one of the freely available ones, made by Thorsten Pawletta at the University of Wismar, Germany The Java program was implemented with functions for accessing XML documents through the Document Object Model, DOM, a standard recommended by W3C DOM is an application programming interface that is used to access XML documents from a programming language and navigate through the document in order to perform operations on the structure or content of the data Further was Xpath used, a standard also recommended by W3C, a query language for

3 XML Xpath was used to specify where to fetch data from the XML document and where to place new information The DOM API Xalan from The Apache Software Foundation, was used AN IMPLEMENTATION OF THE INTERMEDIATE LANGUAGE In XML, XML-Schema, a standard recommended by W3C, can be used to define what information should go in an XML document and how it should be structured to be correct We use it here to describe the different parts of the intermediate language implemented An XML document of the implemented intermediate language has a data structure as shown in Figure 3 It has a root element called Modelith Then, it has three classes, as they are called in Modelica; implemented by the elements type, model and connector directly under the root The names of the elements come from the Modelica language, which is the case for most of the Modelith language As in objectoriented languages, instances of these classes can be created The class is used as a kind of template optional changes_value element part of the uses element can eg be used to change the unit of a variable part of the base class Figure 5 One of the top elements, in this Case type Instances of the connector class are used as connection points for model instances It could eg be a resistor port or motor shaft A connector element contains a number of variables implemented by type_instance elements Each such element here has an extra attribute named prefix that tells whether the variable should be summed to zero or be set equal with respect to corresponding variables in all other connectors connected to If a resistor port was defined, the prefix attribute for the current variables would be set to flow and the variables be summed to zero in each crossing If the prefix attribute is missing all variables are assumed to be equal, having the same effort The model class, shown in Figure 6, is the central class in the language It can as the other classes make use of inheritance It is here that the three levels mentioned earlier; the implicit, flattened implicit and flattened explicit are defined Figure 3 The Top Element of the Intermediate Language Schema In Figure 3, squares indicate XML elements, rounded squares choices, sequences or groups and dashed lines indicate that the element is optional Plus signs indicate that some information in the figure is hidden The schema and the pictures have been created in XML Spy (Kirn 2002), which is a powerful editor for XML (wwwxmlspycom) The schema used by the authors is found at their URL, An XML document that is valid when compared to the schema above (ignoring hidden information in the schema) could be the following: <Modelith> <model/> <connector/> <type/> <model/> </Modelith> Figure 4 Modelith Document Sample The type class, implemented as in Figure 5, is the most fundamental one Type instances, implemented as type_instance elements, are used as variables, parameters and constants By itself the class specifies eg what unit the instances should use The type element has one optional element, as also the model and connector elements have The uses element there tells what class the current class, in this case type, uses as base for adding further information It is this element that makes it possible to inherit variables, connectors etc from other classes The Figure 6 The Central Class, model in which eg all Equations are Placed

4 Object-oriented implicit model The implicit part of a model, shown in Figure 6, contains a number of internal variables, parameters and constants as realised by type_instance elements with a prefix attribute telling which of the mentioned kinds is to be used The connector_instance elements define the connectors on the model that other models can connect to The model can contain instances of other models that can be connected together using connection elements Each of these makes a connection between two model instances by specifying which connector instances on them to connect Finally, the model can contain a number of equations The authors have chosen to use a subset of MathML, a standard recommended by W3C, for the equations, see Figure 7 The equations are then unfortunately not easy to read as pure strings, but are much easier to transform, and it can be used to produce typeset equations for documentation for MathML enabled browsers XSLT is not well suited for string manipulation, therefore it is better to have an XML representation of the equation This also gives the possibility to validate equations against the schema Usermade functions can be referred to here with any number of arguments A future extension of the schema would be to include algorithms so that these functions can be specified directly and thus not be external The MathML functions supported in this schema are plus, minus, times, divide and diff where diff is differentiation with respect to some variable specified in the bvar element, normally set to time To reference variables part of connector instances, the subscript notation of MathML is used, as can be seen in Appendix B and D connections have been transformed into equations using the causal information found in the connector classes At the end of the flattened part, the explicit part with its extra information can be added Figure 8 The Flattened Part of a Model The Elements have the Same Contents as in the Object-Oriented Part Explicit part of the flattened implicit model This part, shown in Figure 9, holds information that helps in simulating the flattened model All type instances of parameter and constant type are left in the implicit flattened part as well as all connector instances The rest of the type instances are here together with all found from expanding the connector instances The prefix attribute is set to input, output or nothing for all type_instance elements so that the output transformer knows how to define the interface to the model A prefix attribute set to nothing would mean that the variable is an internal one In this case, if the prefix attribute in a type_instance in a connector element referred to by an expanded connector_instance element has the value flow, the prefix attribute in the corresponding type_instance element in the explicit part is set to output and vice versa An extra attribute named connector_instance tells whether the type instance comes from an expanded connector instance and if so, from which one Figure 7 The Content of Equations and Jacobian Elements, ie MathML Expressions Flattened implicit model This part, shown in Figure 8, contains a number of type instances, optionally connector instances and finally equations The elements are equal to the ones found in the object-oriented part of the model The difference is that all elements from inherited models have been added and that Figure 9 The Explicit Part of a Model

5 In simulation, the variables need to be calculated The equation system formed by the equations then needs to be solvable Therefore, the MathML diff function is here replaced with a time discrete expression In this implementation, the authors have chosen to insert new type instances with names that are formed from the arguments to the diff functions Each new type instance generates an equation where a time discrete expression is stated In Equation (1) below, the variable x is calculated using the trapezoidal rule There, h is most recent simulation time step, delay is a function that delays the second argument the time specified by the first and der_x is the new variable that is the time derivative of x (der _ x + delay(h, der _ x)) x = delay(h, x) + h (1) 2 The other way would be to use the bilinear transform, as is done in (Krus 1996) This however demands the usage of more powerful symbolic math operations that can be performed for example by using the symbolic math package Mathematica (Wolfram 1999) Since, in the general case, the equation system could be non-linear, a Jacobian is also formed so that the Newton- Raphson solve method can be used The Jacobian is defined for the left-hand side of the equations and therefore all equations from the flattened implicit part are copied to the explicit part and transformed so that the right hand side is zero The Jacobian has a number of rows and each row has an element element Each element contains a MathML expression that is the derivative of the equation referred to by the row number and with respect to a certain variable The variable in question is from the list of type_instance element in the explicit part with the prefix attribute set to output or nothing, at the position determined by the position of the element in the current row of the Jacobian IMPLEMENTATION OF THE TRANSFORMERS Input transformer As an example modelling language to translate, the authors chose Modelica since it is widespread and is one of the most complete languages available A Modelica parser was created as well as a tree builder that outputs an XML file The free parser generator JavaCC (Microsystems 1998) was used A parser, explained in (Levine et al 1992), finds certain units of information in its input These units are specified in a grammar The unit left_bracket_key eg, found there, is the character ( As an example, the Modelica input shown below is transformed into the following XML information model a end a; <Modelica> <model_definition> <class_definition> <model_key/> <IDENT>a</IDENT> <class_specifier> <end_key/> <IDENT>a</IDENT> </class_specifier> </class_definition> <semi_colon_key/> </model_definition> </Modelica> Figure 10 The XML-Transformed Modelica Document The shown XML file can then be transformed into the Modelith language using eg XSLT Flattening This operation is performed in several steps, each with an XSLT file as input specifying how the incremental transformation is to be performed The user specifies a model to flatten The inheritance in all classes is substituted so that the classes are complete by themselves and do not reference anything outside the class The flattened part also contains all equations that have been collected from inherited models as well as the current model If a model that is inherited contains connections, these are transformed into equations in a way that is determined by the type of variables part of the connectors, as explained earlier The name of a variable in an equation is determined from where in the hierarchy a model resides with respect to the toplevel model in order to avoid name conflicts Compare this to the variable naming conventions found in C++ or Java From equations to calculations The connector instances in the flattened model are expanded so that a number of variables can be extracted The generated type_instance elements contain an extra attribute called connector_instance that tells which connector instance in the model they belong to The equations of the flattened model are first brought to the input format of the symbolic math package using XSLT Then, all terms on the right hand side of each equation are moved to the left side and the right hand side is set to zero to be able to differentiate and establish the Jacobian All differentiation functions are replaced by new type instances and each new type instance generates a new equation with a time discrete expression that calculates an approximation of the derivative The equations as well as new type instances are added to the explicit part of the document Now, each element in the Jacobian is calculated The expression to be differentiated is sent to the symbolic math package together with the name on the variable to differentiate with respect to An equation is returned with the differentiated expression, which is transformed to MathML and added to the explicit part Output transformer Here, we focus on the creation of simulation models rather than creation of stand-alone simulators, applications or graphical and textual presentations A simulation model that makes use of the solver in the tool exported to is here called continuous The other type of model that could be output is the one that includes its own solver, here called a discrete model Both can be created from the information part of the explicit model, at least if

6 the derivatives are expressed explicitly, otherwise only the discrete model can be created Output transformers have been implemented and tried for Mathwork s tool Matlab/Simulink (both continuous and discrete S-functions) in (Johansson et al 2002) and for the free simulation package Hopsan (Larsson et al 1998) as shown in the next chapter Hopsan is developed at the division of Mechanical Engineering Systems and is mainly intended for mechatronic systems AN EXAMPLE The mass and spring system shown in Figure 11 is used as an example in the following text The Modelica code is found in Appendix A The example is a mass and a spring The connector instances of the Modelica component are n1 and n2, k is the spring stiffness and endpos the position of the mass where the spring starts to act n1 n2 endpos Figure 11 The Example Model The connector instances define the interface to the outer world Normally, forces and velocities would be the variables to solve for numerically In this example however, the component is to be used in the simulation tool Hopsan Hopsan makes use of bilateral delay lines, described by (Auslander 1968) and (Johns and O Brien 1980) where it is referred to as Transmission Line Modelling (TLM) This is used to numerically integrate a system of ordinary differential equations The connector MechanicQNode therefore contains two extra variables that have the prefixes set to wave and impedance, a small extension to the Modelica language The model TwoFlange also contains one equation for each connector instance that calculates the force acting on the mass using the wave and the impedance given from external components in Hopsan The model TransMass inherits TwoFlange and adds an equation for the mass inertia and the force from the spring After running the Modelica code through the input transformer, the code in Appendix B is produced This file is considerably longer, but also tagged with its information type Maybe most notably, the equations are now in MathML form After having flattened the model TransMass, the code found in Appendix C is added to TransMass model in Appendix B This part of the model now contains all elements found in TwoFlange and TransMass, eg connector- and type instances as well as equations The file in Appendix C can now be used to extract extra information that is added as a new element with name explicit in the flattened part, shown in Appendix D This contains all type instances that are variables from the flattened part as well as two new ones with name der_n2_x and der_n2_sx These are approximate k derivatives of the variable x of connector instance n2 and variable sx of connector instance n2 respectively They are part of two new equations that have been added as well As can be seen, the equations are now in a form where the right hand side is equal to zero A Jacobian can now easily be established From the information found in the complete Modelith file, any type of output can now be created in the general case It can be a Modelica file, a Matlab/Simulink continuous/discrete S-function, HOPSAN or something else In this example, the output is a kind of discrete component since the numerical integration is taken care of by the component itself The output transformer is in the form of one XSLT file of about 350 lines of code Half of this file deals with transforming the MathML equations into appropriate FORTRAN code and the other half is the supporting parts of the FORTRAN subroutine Position (n2x) [m] Time [s] Figure 12 Simulation Results from Hopsan When running the generated component in a Hopsan simulation where a force is given as a step from the left, the position and velocity varies repeatedly as shown in the figure above The mass bounces repeatedly against the spring FUTURE WORK The Modelith XML schema presented in this paper should represent a good start for anyone interested in transforming simulation models To increase simulation performance, a number of things can be done The most import one is transforming the Jacobian into Block-lower-triangular form so that the evaluation of the equation system can be split into several parts Another research area is to include Modelith in a framework for the whole product model including information such as requirement specifications and geometric data CONCLUSIONS It is shown in the paper that the work needed for a user to translate equations into implemented calculations can be dramatically reduced by introducing an intermediate language together with some well-defined transformers that act incrementally on this language The only work needed by the user is to make use of a ready-made intemediate language and transformers and create one or more transformers that import or export models from the Velocity (n2sx) [m/s] (dashed line)

7 intermediate language One or more of the latter could have been created earlier by another user DISCUSSION Since the transformers can be developed individually and since only freely-available programming languages and tools are needed, the framework can act as a catalyst, encouraging cooperation, in the area of modelling and simulation Hopefully, this will lead to the creation of special-purpose modelling languages, new modelling- as well as simulation tools and also translators for physical systems model languages This in turn would give a larger degree of freedom for users of simulation when it comes to defining models, choosing simulation tools and creating custom applications from the models The implementation of the framework shows that most of the work regarding creation of the internal transformers for the intermediate language This work that is however only done once The import and export transformers are easy and quickly implemented using all facilities of the XML domain, this part is hopefully where most of the users will find themselves New user groups such as teachers and engineers can be reached due to the new simple way of translation They will be able to develop simulation solutions for education and special-purpose simulators REFERENCES Auslander DM, 1968 Distributed System Simulation with Bilateral Delay-Line Models Journal of Basic Engineering, No90 (June), Elmqvist, H; Mattsson, SE; and Otter, M 1999 Modelica - A Language for Physical System Modeling, Visualization and Interaction Plenary paper 1999 IEEE Symposium on Computer-Aided Control System Design (Hawaii, August 22-27), IEEE, Harold, E R and Means, E S 2001 XML in a Nutshell O'Reilly & Associates IEEE Working Group: Analog and Mixed-Signal Extensions for VHDL Johansson, B; Larsson, J; Krus, P; and Sethson, M 2002 An XML-based model representation for model management, transformation and exchange To be presented at the ASME Symposium on Automated Modelling (New Orleans,Louisiana, Nov17-22) ASME Johns, P B and O'Brien, M 1980 "Use of transmission line modelling (tlm) method to solve nonlinear lumped networks" The Radio Electron and Engineer No50 (Jan/Feb), Kirn, L 2002 XML Integrated Development Environments Accelerating XML Application Development In the Interprise Whitepaper, Altova Inc, Beverly, USA Krus, P 1996 An Automated Approach for Creating Components and Subsystems for Simulation of Distributed Systems In 9th Bath International Fluid Power Workshop Burrows, CR and Edge, KA (Eds) Research Studies Press Larsson, J; Jansson, A; and Krus, P 2002 User s guide to Hopsan - An integrated simulation environment Technical Report LiTH-IKP-R1258, Mechanical Engineering Systems, Linköping University, Linköping, Sweden Levine, J R; Mason, T; and Brown, D 1992 Lex & Yacc O Reilly & Associates, Inc, Second Edition Microsystems, S 1998 Java Compiler Compiler Technical Report, Sun Microsystems Modelica Association 1999 Modelica A Unified Object- Oriented Language for Physical Systems Modelling, Language Specification Murray-Rust, P; Rzepa, HS; and Wright, M 2001 Development of Chemical Markup Language (CML) as a System for Handling Complex Chemical Content New Journal of Chemistry, No25:4 (March), Otter, M and Elmqvist, H 1995 The DSblock model interface for exchanging model components, In proceedings of the 1995 EUROSIM Conference (Vienna, Austria, Sept11-15) Elsevier Science Publishers, Piela, P; Epperly, T; Westerberg, KM; and Westerberg, W 1991 ASCEND: An object-oriented computer environment for modelling and analysis: the modelling language Computers and Chemical Engineering, No15:1, Ward, RC; Kruse, KL; Allgood, GO; Hively, LM; Munro, NB; and Easterly, CE 2001 "Virtual Human Project," in Proceedings of AeroSense 2001 Meeting (Orlando, FL USA, April 16-20) Wolfram, S 1999 The Mathematica Book, 4 th revised edition, Cambridge University Press APPENDIX A MODELICA SUBSET DOCUMENT type Position = Real(unit="m") type Velocity = Real(unit="m/s") type Force = Real(unit="N") type MechImpedance = Real(unit="Ns^2/m") "Mechanical impedance"; type Mass = Real(unit="kg") "Mass"; type TransStiffness = Real(unit="N/m") "Translational stiffness"; connector MechanicQNode "Node for usage with the TLM technique" Force F; wave Force cx "Characteristic wave"; impedance MechImpedance Zx "Characteristic impedance"; flow Position x; flow Velocity sx; end MechanicQNode; model TwoFlange MechanicQNode n1 "Left mechanical node"; MechanicQNode n2 "Right mechanical node"; equation n1x = -n2x; n1sx = -n2sx; n2sx = der(n2x); n1f = n1cx + n1sx*n1zx "TLM eq for node n1"; n2f = n2cx + n2sx*n2zx "TLM eq for node n2"; end TwoFlange; model TransMass extends TwoFlange; parameter Mass m=100 "The mass"; parameter TransStiffness k=1e+5 "Spring constant for right end pos"; parameter Position endpos=10 "End position"; equation n1f-n2f-onpositive(n2x-endpos)* (n2x-endpos)*k = m*der(n2sx) "Newtons 2:nd with an end spring"; end TransMass;

8 APPENDIX B OBJECT-ORIENTED IMPLICIT MODELITH DOCUMENT <Modelith> <type name="position"> <uses class="real"> <changes_value type_instance="unit" value="m"/> </uses> </type> <connector name="mechanicqnode" comment="a node for usage with the TLM technique"> <type_instance name="sx" prefix="flow"> <uses class="velocity"/> </type_instance> </connector> <model name="twoflange"> <connector_instance name="n1" comment="left mechanical node"> <uses class="mechanicqnode"/> </connector_instance> <connector_instance name="n2" comment="right mechanical node"> <uses class="mechanicqnode"/> </connector_instance> <equation> <MathML> <apply> <eq/> <ci> <msub> <mi>x</mi> <mi>n1</mi> </msub> </ci> <apply> <minus/> <ci> <msub> <mi>x</mi> <mi>n2</mi> </msub> </ci> </apply> </apply> </MathML> </equation> </model> <model name="transmass"> <uses class="twoflange"/> <type_instance name="m" prefix="parameter" value="100" comment="the mass"> <uses class="mass"/> </type_instance> <equation> </equation> </model> </Modelith> APPENDIX C FLATTENED IMPLICIT PART OF MODEL <flattened> <connector_instance name="n1" comment="left mechanical node"> <uses class="mechanicqnode"/> </connector_instance> <type_instance name="m" prefix="parameter" value="100" comment="the mass"> <uses class="mass"/> </type_instance> <equation> </equation> </flattened> APPENDIX D EXPLICIT PART OF FLATTENED IMPLICIT MODEL <explicit> <type_instance name="f" prefix="output" connector_instance="n1"/> <type_instance name="cx" prefix="input" connector_instance="n1"/> <type_instance name="zx" prefix="input" connector_instance="n1"/> <type_instance name="x" prefix="output" connector_instance="n2"/> <type_instance name="sx" prefix="output" connector_instance="n2"/> <type_instance name="der_n2_sx" prefix="derivative" state="sx" connector_instance="n2"/> <type_instance name="der_n2_x" prefix="derivative" state="x" connector_instance="n2"/> <equation> <MathML> <apply> <eq/> <apply> <plus/> <ci> <msub> <mi>x</mi> <mi>n1</mi> </msub> </ci> <ci> <msub> <mi>x</mi> <mi>n2</mi> </msub> </ci> </apply> <cn>0</cn> </apply> </MathML> </equation> <jacobian> <row> <element> <MathML> <cn>1</cn> </MathML> </element> </row> </jacobian> </explicit>