This stereotype has attributes that are common to all Modelica restricted classes. This is the path to the icon image relative to the location of the model file. Modelica "function" resembles the Modelica "block" but it: - can only have inputs and outputs; no connectors - does not have a connectable interface but instead needs to be called - can be called recursively - is more dynamic; the arguments are computed at run-time - does not have internal states - can have only one algorithm section and no equation section; is always imperative - becomes part of the equation system as black boxes only; the internals are not manipulated symbolically by the solver

This stereotype is used to represent the Modelica "block". Modelica "block" is the same as Modelica "model", but the ports (instances of "connector" classes) must have fixed causality (i.e. "input" or "output").

This stereotype is used to represent the Modelica restricted class "model". All the following Modelica class elements are allowed in models: Both equation and algorithm sections; connectors, inputs, outputs; states;

This stereotype is used to represent the Modelica restricted class "package".

This stereotype is used to represent the Modelica restricted class "connector". A "connector" cannot contain equation or algorithm sections, it can have causality and flow specification. All ports must be typed by a "connector".

This stereotype is used to represent the Modelica "record". A Modelica "record" cannot contain equation or algorithm sections and does not contain causality and flow specification.

This stereotype is used to represent the Modelica restricted class "type".

A CalculationModel is a sub-type of Modelica "model". It is defined in order to enable reusing of equations. It does not represent a physical system part and cannot have external connectors. When instantiated, it calculates values that are used by other components.

This stereotype is used to represent the Modelica "class".

This stereotype is used to represent the Modelica restricted class "operator".

This stereotype represents an existing Modelica model that is included as black-box into ModelicaML model. This string is the absolute model path (dot-notation, starting with the top-level package) to the referenced model.

This stereotype has attributes that are common to all Modelica class instances. Each entry represents one instance modification of type "instance name = modification expression". The parenthesis "(" and ")" and the commas are omitted. Each entry string contains the full specification of the array. For example, "[1,3,:]". Only if the condition is true then the Modelica component is created; the condition is only evaluated at compilation time and is often used for configuration changes. The result of expression must be of type Boolean. This string contains the expression. The keyword "if" is omitted. This is the path to the icon image relative to the location of the model file. If no icon is defined for a property then the icon of the property type is displayed (if defined, else no icon is displayed). This stereotype is used to represent a Modelica component of a composite type.

This stereotype is used to represent a Modelica class instance of the type "connector".

This stereotype is used to represent a Modelica class instance of a primitive type (Real, String, Boolean, Integer) or a sub-type of Modelica restricted class "type". This refers to the shorthand notation in Modelica. The result must be of the same type as the Modelica component itself. In this case the value is the right-hand-expression of the equation or assigment. The "=" or ":=" sign must be included.

This stereotype is used to represent the Modelica "connection" clause and implies its associated semantics (Kirchhoff's laws). This property can be used to define the content of a Modelica connect clause. The keyword "connect" and the parenthesizes are omitted. The string must contain paths to both ports (using the dot-notation) separated by comma. Example: component1.port1.variable1 , component2.port2.variable2 This stereotype is used to represent variables of functions. This refers to the shorthand notation in Modelica. The result must be of the same type as the Modelica component itself. In this case the value is the right-hand-expression of the equation or assigment. The "=" or ":=" sign must be included. Does not represent a physical system part. This component supplies other components with calculated values.

This stereotype is used to represent a set of statements in an algorithm section. This stereotype is used to represent a set of equations in an equation section. This stereotype is used to represent the Modelica "if" keyword. This stereotype is used to represent the Modelica "when" keyword. This stereotype is used to represent an algorithm section. An Activity Diagram is used to model the conditional constructs (loop, if, when). Any OpaqueActions, in such an Activity Diagram, must contain Modelica statements in the "body" attribute. This attribute indicates that this activity is a sub-activity. It is invoked by another activity using CallBehaviorAction. This stereotype is used to represent an equation section. An Activity Diagram is used to model the conditional constructs (loop, if, when). Any OpaqueActions, in such an Activity Diagram, must contain Modelica equations in the "body" attribute. This attribute indicates that this activity is a sub-activity. It is invoked by another activity using CallBehaviorAction. This stereotype has properties that are inherited by other stereotypes in order to be able to capture the "for" or a "while" loop with the "for-indices" or "while expression" respectively. This stereotype has properties that are inherited by other stereotypes in order to be able to capture the "for" loop with the "for-indices". This stereotype is used to represent a set of equations in a diagram. This stereotype is used to represent a set of algorithm statements in a diagram. This stereotype represents the Modelica assert() function. This stereotypes indicates that this a special case of the UML StateMachine. It uses a limited set of the UML StateMachine meta-model classes. It is capable to be translated into executable Modelica code. Reference to a state in one of the state machines of the class. The logical operator to be used between the multiple state references. Execution priority in code. A lower number implies a higher execution priority. Elements with higher priority are executed first. If set to true then exit actions of the transition source-state and its sub-states are not executed. If set to true then entry actions of the transition target-state (not its sub-states) are not executed. The state machine or the composite state is fozen, i.e., the state is active but no reactions and no actions will be executed inside the state, as long as this expression evaluates to true.

This stereotype has attributes which allow the capturing of type modifications. It can only be used between classes of primitive type. Each entry represents a Modelica type modification. Commas and the parenthesis "(" and ")" are omitted. Each string contains the full array specification (e.g. "[1,3,:]") This stereotype has attributes which allow the capturing of type modifications. Each entry represents a Modelica type modification. Commas and the parenthesis "(" and ")" are omitted.

The concept of textual requirements is reused from the OMG SysML. This stereotype is used to represent a requirement with properties such as id, text (representing the textual statement), etc. Moreover, a requirement can have variables and behavior defined which can be evaluated during simulations. Requirement ID. Textual requirement statement. This property implies that all instantiated objects of the referenced types shall fulfill this requirement. This property implies that only the referenced objects shall fulfill this requirement.

This stereotype indicates that this component is an instantiation of a requirement.

This stereotype can be applied to any model element. It has properties that can be used for setting up the traceability between requirements and design artifacts.

This stereotype contains the properties which are used in the "simulate()" command in Modelica tools. This stereotype is used to indicate that the value of this variable shall be manipulated by the user. Therefore it is necessary to set the variability to "parameter" (this requirement is OMC-specific). Moreover, the modeler can define declaration value for the parameter if necessary. Declaration value for the parameter. This stereotypes is used to indicate that this behavior shall be excluded from the code generation if the referenced variable is set to be user interactive (variability is set to "parameter"). Reference to the variable that is user interactive (must have the stereotype <<UserInteractive>> applied) and thus does not need the behavior (equations or algorithm) for its calculation. This stereotype is used for caturing of code generation specific information. If this property is set for a class the code generator will generate an init-file that is required for the interactive simulation (OMC specific). This flag indicates that no code shall be generated for this element.

See the Modelica specification. See the Modelica specification. The experiment annotation defines the default start time (StartTime) in [s], the default stop time (StopTime) in [s], and the default relative integration tolerance (Tolerance) for simulation experiments to be carried out with the model or block at hand. Annotations are intended for storing extra information about a model, such as graphics, documentation or versioning, etc. A Modelica tool is free to define and use other annotations, in addition to those defined here, according to section 14.1. of the Modelica specification. The only requirement is that any tool shall save files with all annotations from this chapter and all vendor-specific annotations intact. To ensure this, annotations must be represented with constructs according to the Modelica grammar. The specification in this document defines the semantic meaning if a tool implements any of these annotations. This is a qualified annotation string. The first "(" and the last ")" are omitted. A top-level package or model can specify the version of top-level classes it uses, its own version number, and if possible how to convert from previous versions. This can be used by a tool to guarantee that consistent versions are used, and if possible to upgrade usage from an earlier version to a current one. Defines the version number of the model or package. All classes within this top-level class have this version number. The first "(" and the last ")" are omitted. The first "(" and the last ")" are omitted.

Test suite is a collection of test scenario that are grouped for specific purpose. List of test scenarios that test suite contains. Test scenario a step by step description of action that stimulate the system under test. Usually a test scenario also includes the initialization of the system under test in order to ensure the required pre-condition are met. Test scenario may used to verify system design against system requirements. This relation indicates that this test scenario can be used to verify the listed requirements. This relation indicates that the test scenario, it points from, can be used to verify the requirements it points to. This relation indicates that the test suite, it points from, contains the test scenario it points to. This dependency indicates that when the client model is instantiated it requires the target model to be instantiated as well. This property means that the target model shall be instantiated together with the client model only if listed (other) models will be instantiated too. This property means that the target model shall always be instantiated together with the dependency client model. A Test model typically includes one system model that is to be verified against requirements models by means of one test scenario model. This stereotype is the opposite of the "requires" stereotype. The two stereotypes are mutually exclusive and should be used depending on the desired direction of the dependency and the resulting modification of the dependency client.

If set to true this property means that this client always needs a bindings even if a default value is set in its declaration.