Unified Modeling of Real-Time Control Systems and their Physical Environments Using UML Jakob Axelsson Carlstedt Research & Technology AB* SE-411 21 Göteborg, SWEDEN E-mail:
[email protected]
Abstract Modeling languages that are used to capture the essential properties of embedded real-time computer systems must also allow a description of the system’s physical environment. The reason is that the environment is the ultimate source of all requirements on the system, and in particular, real-time constraints are derived from the dynamics of the physical objects under control. However, most modeling languages, including the object-oriented ones, are not well equipped to describe the continuous-time relationships that exist in the real world. This paper shows how the Unified Modeling Language can be extended to include such modeling, thereby improving the design of embedded systems described in the same language. A realistic case study is elaborated to show the practical usefulness of the results.
1. Introduction Most complex technical systems rely on the use of embedded real-time computers to control and monitor their operation. It is well known that the complexity of such embedded systems has to be mastered through the use of rigorous development methods, allowing the designers to assess the quality of the solution throughout the various stages of the development. Currently there is a lot of interest in object-oriented (OO) techniques, that are based on “natural” concepts, such as objects, relations, states, and events, that are easily distinguishable in the real world. They have the benefit of being well suited for reusability, by organizing hierarchical libraries of standard components that can be connected to form a complex system. Lately, an effort has been made to standardize the notation, resulting in the Unified Modeling Language (UML) [5]. The OO methods originally aimed at general software development, thus focusing on the description of the software inside the system and the interaction with external * This work was mainly done while the author was with Volvo Technological Development Corporation.
(human) users. However, embedded systems also interact with an external physical environment in order to control or monitor it, as shown in Figure 1, and as every control engineer knows, information about the physical environment is crucial in the design of the embedded system. Therefore, the typical control engineer spends a substantial amount of time in modeling the environment, using laws of physics, or models based on empirical data. The models are based on differential equations that describe how the values of variables evolve dynamically over time. The dynamics of the external environment is translated into real-time constraints that apply to the internal design of the embedded controller. It is impossible in practice to correctly state those constraints on a complex real-time system without good models of the environment, which makes research into such modeling very important for the real-time systems area. The environment is also important from a system safety perspective. It has been shown, e.g. in [4], that the two most important safety hazards are misunderstandings in the requirements specification and in the interface to the rest of the system. A thorough modeling of the system and its environment helps improve these two aspects. Since the embedded system and the environment form a whole, it would be beneficial to model them together in one complete model, and from the standpoint of the embedded software developer, it would be best to use a notation such as UML which has already been proven in this field rather than to invent a totally new language. However, UML does at first glance not lend itself well to the modeling of physical pro-
Control System Operator
Environment
Figure 1. The relation between the embedded controller and its environment.
cesses, since it is based on a discrete dynamic model where the system changes state as a result of events, whereas the external world changes state continuously. Nevertheless, after a closer examination it turns out that UML indeed contains sufficient elements and extension mechanisms to use it also for continuous modeling, and the prime contribution of this paper is to show how it can be done. By allowing the control engineers and software engineers to use the same models, much redundant work is avoided and sources of misunderstanding are removed, leading to faster development and higher quality. In the next section, it is described what characteristics an OO modeling language should have in order to be suitable for continuous-time models. In Section 3, an overview is given of those parts of UML that are needed in the paper. In Section 4, an adaptation of UML to physical modeling is described, which provides the desired features using a small number of extensions expressed in the mechanisms provided in the language, and in the following section, the notation is illustrated by an extensive case study. In Section 6, some related work is described, and finally in the last section the conclusions are summarized.
following features need to be added: 1. Continuous variables. Variables whose values’ are changing continuously as functions of time, to represent the current state of the physical system. 2. Equations. Equations that relate the variables to each other, describing the dynamic behaviour of the system. 3. Time and derivatives. Physical laws are mostly differential equations, so a way of referring to the current time and to the derivative of expressions is needed. 4. Modes. Realistic physical systems have different modes, i.e. they behave differently depending on whether certain variables have values in specific ranges. Ways of describing the modes, the relations that hold in each of them, and the transitions between them, are needed. 5. Composition. To construct large models, convenient ways of composing models of parts from libraries are needed. Preferably, mathematical relations that are required to specify how the connections are made, such as Kirchoff’s laws, should not have to be restated every time two model elements are connected.
2. Requirements on modeling languages 3. Overview of UML The purpose of a modeling language is to support the system developers throughout the process from initial specification to finished product, and enable them at various stages to make predictions about the final system’s characteristics, in particular related to its functionality and performance. Therefore, for embedded systems the following features are required of a modeling language: • Since the system is closely related to its environment, which is usually physical, it must support modeling of continuous behaviours. • The internal parts are mostly logical, thus the system must be able to support discrete behaviour as well, including behaviour where the structure changes dynamically, as may be the case for software. • It should allow efficient modeling, in the sense of short time to construct models, in order to reduce lead times, and must therefore support reuse of models. As argued in [8], today’s most common method for modeling physical systems, using data-flow block diagrams, have problems meeting several of these needs. Although there are extensions which allow the addition of finite-state machines, the structure remains fixed and reuse is difficult due to the unnatural causality introduced in the models. On the other hand, the OO modeling languages, such as UML, meet all these requirements, except for that concerned with the physical modeling. To be more specific, the
In this section, an overview of UML is given. The discussion is limited to those concepts that are needed to understand the rest of the paper, and the reader is referred to e.g. [5] for information about the rest of the language. UML’s graphical notation is shown in the case study in Section 5 that illustrates the proposed extensions.
3.1. Objects, classes, and packages The fundamental concept of OO methods is the object. An object consists of a set of attributes, or variables, which describe its internal state, and a set of operations that the object can perform, e.g. to update or query the state, or perform calculations. An object is an instance of a class, which can be thought of as a set of objects with similar properties, i.e. the same attribute and operation names, and the information about the properties is normally provided at the class level. At a given time, there may be several instances of each class, and the instances may have different attribute values. Classes are shown as boxes with the name inside it. Alternatively, the box may be divided into three compartments, containing the class name, the attributes, and the operations, respectively. Objects are also shown as boxes, with the difference that the object name is underlined to show that it is an instance, rather than a class. Objects and
classes may be grouped into packages, to structure large systems into subsystems.
3.2. Links and relations It is possible to define links between objects (shown as a line between them), that allow objects to refer to each other, e.g. to invoke an operation in a related object. The links between objects are instances of relations between the corresponding classes. The relations can be either general associations, which have no special meaning (shown by a line between the classes); aggregations, indicating that an object is part of another object (shown by a line with a diamond attached to the end connected to the “owning” class); and generalization, which describes a relationship between classes similar to the subset relationship between sets (shown by a hollow arrow head attached to the end near the more general class). The class that is a specialization can be thought of as inheriting the features of the more general class, thereby allowing information to be reused. It is possible to add a role name to the association, indicating by what name an object refers to the other object in the relation, i.e. the attribute a of the class related by the role r is referred to by the name r.a.
3.3. State machines To each class, a state machine may be attached, which shows the dynamic behaviour of the class’s objects. States are shown as ovals, and transitions as arrows between them. The transitions of the state machines are triggered by events, which cause the transition to occur. An event may e.g. be the invocation of a class’s operation, or some condition, expressed in terms of the attributes, being fulfilled. It is also possible to have actions on the transitions, that are performed whenever the transition is followed, and this can be used e.g. to update attribute values.
3.4. Extension mechanisms The notations provided in UML are general, but it is also possible to add domain-specific extensions to the language. This includes constraints which limit e.g. attribute values. Constraints are written inside {...} in a box attached to the model element to which it applies. New semantic information may be added through the use of stereotypes, which are annotations to modeling elements. For instance, all classes that are of a certain stereotype could have a semantic addition that they may only be related to other classes with the same stereotype. Stereotypes are indicated by writing their names inside «...».
4. Adapting UML In this section, we describe an extension to UML, that allows us to model physical systems. The goal is to make as few additions as possible to the language using its extension mechanisms, while still fulfilling the requirements described in Section 2.
4.1. Continuous variables The extension should be able to handle continuous variables that model properties of the physical system and couple them to the objects whose state they describe. Therefore, the natural solution is to use ordinary real-valued attributes in UML, and make the somewhat liberal assumption that a real number is really a real, in the mathematical sense, and not a limited precision floating point number, as in most computer implementations.
4.2. Equations It should be possible to use equations to relate different variables to each other. The meaning of such an equation would be to express an invariant between the variables, i.e. a relationship between their values which holds under all circumstances. Incidentally, the concept of invariants is fundamental to computer science, although it is mostly used to express logical relations, and therefore UML has already incorporated the stereotype «invariant», which is attached to constraints of different modeling elements such as classes. Again, we interpret the concept liberally, assuming that the variables involved in the invariant are not only altered in discrete steps, but may change continuously.
4.3. Time and derivatives There is a need to refer to the current time, e.g. in order to describe functions that vary over time in a certain way. UML incorporates the notion of time, in the sense that events may be created at a specific time, but this refers to a clock in the system which generates discrete events. For our purpose, we do not wish to involve any notion of clock, and therefore a pre-defined continuous global variable, called time, is introduced to denote the current time. A related problem is the derivative, i.e. rate of change, of an expression. We need to introduce an operator der(x), which denotes the derivative of the expression x with respect to time (der(x) = d x/d time; hence der(time) = 1).
4.4. Modes Often, a realistic system is not totally continuous, but may
operate in a number of different modes. In each mode, a different set of equations is used to describe the behaviour of the system. Mode changes occur as the result of events, e.g. that a variable passes a certain limit. Modes correspond closely to the notion of states in UML, and the mode changes correspond to transitions between states. The equations that govern the behaviour in a mode can be described by an invariant on a particular state, and the full set of equations for the object while in a certain state is the invariants of the class plus the invariants of the current state. UML already contains an event type, called change event, which occurs when a certain expression becomes true, and the notation is e.g. when(x > 10 or y < 0). In fact, UML acknowledges that this kind of event could actually imply the need to continuously check the variables in the when-expression, which is exactly what we intend.
{abstract} ElectricalComponent
pin1 pin2
«port» ElectricalPin voltage «flow» current
Resistor resistance
«invariant» {pin1.current + pin2.current = 0} «invariant» {pin2.voltage - pin1.voltage = resistance * pin1.current}
Figure 2. Model of electrical components.
4.5. Composition
• A relation with the stereotype «connect» only involves objects that are of the stereotype «port».
The concepts introduced so far are sufficient to allow the modeling of physical systems. However, to ease the construction of complex models, and increase the ability to describe reusable components, improved ways of composing models are needed. In particular, the interfaces between objects and the connection of interfaces are of interest. The solution we propose is to introduce the concept of ports, which are interface points of a class. Ports themselves are objects with the stereotype «port». To improve the graphics, the icon is introduced for port instances. To form connections, ports of different objects are linked to each other, and the link has the stereotype «connect». We only allow to connect ports to each other using links with the stereotype «connect», and since that is the only use of this stereotype, we usually let the stereotype on the link be implicit. The port objects contain variables which are related to the corresponding variables of the ports they are connected to. A special kind of variable, with the stereotype «flow», is introduced to model flows of e.g. current and matter. The introduction of these stereotypes allow us to implicitly generate the necessary invariants to make the connections mathematically correct, thereby reducing the effort to build large models.
• Port objects in the same equivalence class must be of the same class, and thus contain the same variables.
4.6. Semantics of composition By taking the reflexive, symmetric, and transitive closure of all links with the stereotype «connect», an equivalence relation is formed over the set of all «port» objects in the model. The equivalence classes of this relation show which ports are logically connected. The semantics are: • A «port» is part of at least one other object via a relation which is not of the stereotype «connect».
• For all variables which do not have the stereotype «flow» of all port objects in the same equivalence class, a set of invariant conditions is added which assures that the variables of each object in the same equivalence class all have identical values. • For all variables which have the stereotype «flow» of all port objects in the same equivalence class, an invariant is added which assures that all such variables of objects in the same equivalence class sum to 0.
4.7. Example of composition: electrical components To illustrate how composition works, we provide as an example a model of ordinary electrical components, as illustrated in Figure 2. The model contains a class ElectricalComponent, which captures common behaviour of electronic components. The class is abstract, meaning that its description is incomplete, and it is therefore not meaningful to instantiate it. However, it serves as a basis for defining concrete subclasses. An electrical component has two ports, pin1 and pin2, of the class ElectricalPin, which has two attributes: its voltage and its current, where the latter is a flow variable. The common characteristic of all electrical components, which is expressed by an invariant on the class, is that the flow of current into the component must be equal to the flow out of it. A special kind of component is the Resistor, which is modelled as a subclass of ElectricalComponent. It has the attribute resistance, and an invariant which expresses Ohm’s law. Note that Resistor
pin1 R2: Resistor
pin1
pin2
R1: Resistor pin2 pin1
R3: Resistor
pin2
practice, we provide a case study. It consists of a controller for an electrical motor which drives a load via a gearbox (similar to the example in [8]). The situation is intended to resemble the early stages of development of the controller, i.e. the capture of requirements and interfaces.
5.1. System overview
Figure 3. Example of composition. inherits both the relations and invariant of ElectricalComponent. Other component types, such as capacitors and inductors, may also be modelled as subclasses of ElectricalComponent, which reveals the power of inheritance. Figure 3 shows an instance of the model, where three resistor objects, R1, R2, and R3, are connected together by connecting their pins. As explained in Section 4.6, the equivalence class corresponding to the logical connection in the figure consists of R1.pin2, R2.pin1, and R3.pin1. The equations which assure that all the voltages are equal at the connection are R1.pin2.voltage = R2.pin1.voltage and R1.pin2.voltage = R3.pin1.voltage. To assure that the same amount of current flows into the connection as out of it, the equation R1.pin2.current + R2.pin1.current + R3.pin1.current = 0 is needed. These invariants correspond to Kirchoff’s laws, and it should be noted that they are automatically derived from the semantics of the port concept. (For other domains, e.g. mechanics, fluid dynamics, similar laws exist, which makes the use of ports very powerful.)
An overview of the system is given in Figure 4. It shows the human operator and two subsystems: the ControlSystem and the Environment, modelled as packages. (The system is thus structured similar to the one in Figure 1.) The operator gives commands to the control system to set a certain speed to the load or change the gear. The control system provides information to the operator about the current status of the system under control, in particular the current speed of the load. It is assumed that the operator is placed at some distance from the objects in the environment, and therefore the control system consists of two computer nodes: the OperatorStation and the Controller (depicted using the UML icon for nodes), connected via a CAN bus. The Controller is linked to a MotorActuator and a GearActuator, responsible for transforming commands from the software to electrical signals, and an RpmSensor which provides the software with the current speed of the load (in rpm). Note that the port icons are used to depict the physical interfaces of the motor, gearbox, and load, i.e. the mechanical axles and electrical pins. The diagram shows objects, rather than classes, since this describes a certain system instance.
5. Case study To clarify how the extended UML notation can be used in Environment
ControlSystem
:Motor :OperatorStation
:MotorActuator
pin pin
Operator «CAN»
:GearActuator
axle
pin pin
:Controller :RpmSensor
«invariant» {momentOfInertia < 100 and abs(der(momentOfInertia)) < 20}
Figure 4. Overview of the system in the case study.
torqueConstant = 0.01 momentOfInertia = 0.001 rotorResistance = 0.5 rotorInductance = 0.05 :GearBox
axle1 forwardRatio = 100 reverseRatio = 50 :Load
axle2
axle
5.2. Environment model The environment contains a Motor, a GearBox, and a Load. The characteristics of the Motor and GearBox are given in Figure 4 as attribute values. The attribute momentOfInertia of the Load is not given a value, but is assumed to vary over time. This variation is not under control of the system, and may thus be regarded as a disturbance for which the controller must compensate. The characteristics of the disturbance are important when it comes to determining the timing constraints of the controller, and are expressed as an invariant The model is refined by providing the definitions of the classes, as shown in Figure 5. The ElectricalPin is reused from the example in Section 4.7, and MechanicalAxle is introduced as a port modeling a rotating axle, with the variables angle and torque. The motor, load, and gearbox «invariant» {momentOfInertia * der(der(axle.angle)) = axle.torque}
«invariant» {der(axle1.angle) = currentRatio * der(axle2.angle) and axle2.torque = currentRatio * axle1.torque}
Load momentOfInertia GearBox
axle «port» MechanicalAxle
axle1
angle «flow» torque
axle2
forwardRatio reverseRatio currentRatio forwardGear() reverseGear()
axle pin
Motor torqueConstant momentOfInertia rotorResistance rotorInductance
pin
«port» ElectricalPin voltage «flow» current
«invariant» {momentOfInertia * der(der(axle.angle)) = torqueConstant * pin.current - axle.torque and rotorInductance * der(pin.current) + rotorResistance * pin.current = pin.voltage torqueConstant * der(axle.angle)}
Figure 5. The classes of the physical components in the environment.
«invariant» {currentRatio = forwardRatio}
«invariant» {currentRatio = -reverseRatio}
when(reverseGear()) Forward
Reverse when(forwardGear())
Figure 6. State machine for the class GearBox. contain attributes representing the characteristics of the component, and invariants are attached to the classes to describe the physical laws that govern their behaviour. The invariant of the gearbox is expressed in terms of the auxiliary variable currentRatio, whose value depends on the direction of movement. The state machine in Figure 6 shows the details of the gearbox. The object responds to two operations, forwardGear() and reverseGear(), which cause transitions, i.e. mode changes, to take place in the state machine, thereby changing the behaviour since a new invariant will determine the current ratio. It is assumed that the two operations return true or false depending on the current value of GearBox.pin.voltage, thereby allowing the gear to be selected using this voltage. (Of course, this model is very simplistic, since it allows an instantaneous gear change while the axles are rotating.)
5.3. Sensors and actuators The sensors and actuators are the interface points between the control system and the environment. Towards the control system, they present a software interface, with operations which may be invoked to query the state of the environment or change the state, respectively. Towards the environment, the actuators provide a port whose attributes can be set to affect the physical process. Figure 7 shows the class diagrams for the sensors and actuators, and Figure 8 shows the state diagram for the sensor. The state diagram shows how a time-out (tm(samplePeriod)) occurring at an interval determined by the sampling period causes the current speed to be updated to the actual value, after conversion from rad/s to rpm. The operation getSpeed() simply returns currentSpeed. The SpeedActuator has an operation setSpeed(s) which changes the value of currentSpeed to s, where the speed is measured between 0 (stand still) and 1 (full speed). The invariant indicates how the given speed is transformed into a current on the pin which drives the motor. The GearActuator works in a similar manner
axle
RpmSensor
«port» MechanicalAxle
currentSpeed prevAngle samplePeriod getSpeed() «port» ElectricalPin pin
GearActuator
pin isForward setForward(f)
SpeedActuator currentSpeed maxVoltage setSpeed(s)
«invariant» {pin.voltage = currentSpeed * maxVoltage }
Figure 7. Sensor and actuator models.
5.4. Embedded system requirements The purpose of the modeling is to provide the information necessary to correctly develop the embedded system. We are especially interested in the early phases, and we therefore now discuss the relation between the models and the requirements capturing. The models provide the vocabulary to use in the requirements, and all the terms employed should be clearly indicated in the model. Therefore, in practice, the models and requirements capturing are activities that proceed in parallel. Often, a first step is to describe scenarios where the system could be used. The terminology in the scenarios are formalized into classes, attributes, and relations, which are then used to describe requirements. Some of the requirements we might wish to pose are: • Functional: describe what the control system’s task is. In the example there are several functions: to maintain the speed close to that indicated by the command from the operator; to select the gear according to the operator’s commands; and to provide feedback concerning the status to the operator.
Hold
tm(samplePeriod) / currentSpeed := ((axle.angle - prevAngle) mod (2 * π)) * 30 / (π ∗ samplePeriod)
Figure 8. Sensor state diagram.
• Performance: determine e.g. how fast the system responds to a change in one of its input signal. These requirements are broken down into timing constraints on the control system, providing sampling periods for sensors, deadlines for software tasks, and priorities for bus communication. • Stability: ensure that the system does not output actuator values which might cause it to lose control of the physical process. This can be analysed by simulating the differential equations in the model. • Accuracy: specify what precision is needed in the control, which affects the choice of sensors and actuators as well as the timing of the system. • Safety: guarantee that the controller does not harm persons or equipment in the environment. As an example, it may be undesirable to perform gear shifts at speeds above a certain value, due to risk of damaging the gear box. The model clearly indicates that the gearbox does not prevent this itself, and a requirement therefore has to be put on the controller to ensure that a gear shift command from the operator is not performed unless it is safe. This can be solved by either ignoring gear shift commands when it is not safe, thereby putting the responsibility on the operator, or enhancing the gear shift function to automatically reduce the speed when a gear shift command occurs, and restore the speed when the gear shift has taken place. Since there is a considerable difference in the functionality of the system, the requirements should clearly state the alternative to use.
5.5. Discussion The modeling described in this case study would be typical for an initial system development phase, where the objective is to specify the control system. The equations in the model can be used by a control engineer to determine what information is available from the environment, and help him find a suitable control strategy and parameters, but it also helps clarifying other relations between the controller and the environment. Another benefit is that it provides a common vocabulary, which can be used by the system engineers, control engineers, software engineers, etc. that participate in the project. As the work proceeds to lower levels, each part of the system can be refined by expanding their internal parts, i.e. replacing the invariants with a number of interconnected parts with their own invariants. To use the language in practice, tool support is necessary, allowing for analysis of the characteristics discussed in Section 5.4, simulation, and semantic checks (including a type check to see that proper scientific units are used).
6. Related work Suggestions have been made on how to use UML for embedded systems, e.g. in [1], but they typically focus on how to handle the internal organization of the system, i.e. what tasks should execute and how they should be scheduled. Other formalism, e.g. SDL [2], suffer from the same limitations as basic UML. The same applies to UML RT/ ROOM [7], although this notation provides some similarities to ours in that it uses a port concept to structure the models. Even if UML RT/ROOM is unsuitable for modeling and analyzing a physical environment due to its lack of mechanisms for handling continuous behaviour, it would be possible to use it to structure the internal software of the system in the design phases. Several OO languages for modeling of physical systems have been proposed. Currently, international efforts are under way in defining the language Modelica [3], which contains most of the concepts included in the UML extension. In particular, the constructs we propose related to composition directly follow the solution in Modelica. However, Modelica does not contain good support for modeling the internal software of the system, which is a requirement for the developer of embedded applications. It can be expected that many simulation packages will support input descriptions expressed in Modelica, and a feasible solution to providing simulation capabilities to the proposed UML extension could be to generate Modelica code from the UML model. We have developed a demonstrator which translates UML models from the tool Rational Rose to Modelica, allowing them to be simulated using tools such as Dymola.
7. Conclusions and future development In this paper, we have attempted to solve the problem of finding a modeling language that could support the development of embedded real-time systems, with focus on control functionality. Such a language must allow the user to model a physical environment which is best described by differential equations involving continuous variables. It must also allow the embedded system, which is usually a discrete software program, to be modelled. The solution we propose is to make a modest extension to UML to allow continuous models. In summary, our proposal is:
Since the dynamics of the physical environment is the source of the timing constraints, the importance of good environmental modeling cannot be overemphasized when it comes to practical development of real-time control systems. We hope that a common language like the one suggested here will be helpful in bridging the gap that today often exists between control engineers and software developers. Although our initial motivation for this work was to support the development of embedded systems, we see wider use of the results. In particular, the area of Systems Engineering requires better modeling practices. In [6], an interesting approach is taken to use OO modeling for this purpose, which could easily be adapted to UML notation. However, since Systems Engineering is usually concerned with problems involving many scientific disciplines, the need for a mixture of discrete and continuous models is almost inevitable, and the use of our notation would therefore increase the power of the models significantly.
References [1] Douglass, B. P. Real-Time UML. Addison-Wesley, 1998. [2] Ellsberg, J., D. Hogrefe, and A. Sarma. SDL: Formal Objectoriented Language for Communicating Systems. Prentice Hall, 1997. [3] Fritzson, P. and V. Engelson. Modelica - A Unified ObjectOriented Language for System Modeling and Simulation. Proc. 12th European Conference on Object-Oriented Programming, 1998. [4] Lutz, R. Analyzing Software Requirements Errors in SafetyCritical, Embedded Systems. Proc. IEEE International Symposium on Requirements Engineering, 1992. [5] Rumbaugh, J., I. Jacobson, and G. Booch. The Unified Modeling Language Reference Manual. Addison-Wesley, 1999. [6] Oliver, D. W., T. P. Kelliher, and J. G Keegan, Jr. Engineering Complex Systems with Models and Objects. McGraw-Hill, 1997.
• To add the notion of time and derivation, der(x).
[7] Selic, B., G. Gullekson, J. McGee, and I. Engelberg. ROOM: An Object-Oriented Methodology for Developing Real-Time Systems. Proc. 5th International Workshop on ComputerAided Software Engineering, 1992.
• To interpret attributes as continuously changing variables, and invariants with respect to classes and states as equations of such variables.
[8] Åström, K. J., H. Elmqvist, and S. E. Mattson. Evolution of Continuous-Time Modeling and Simulation. Proc. 12th European Simulation Multiconference, 1998.
• To introduce stereotypes for ports, flows, and connections, to facilitate the construction of large models.
