A SysML extension for Bond Graphs support Skander Turki Thierry Soriano LISMMA (EA 2336) Supmeca Toulon Maison des technologies Toulon 83000, France skander.turki@supmeca.fr LISMMA (EA 2336) Supmeca Toulon Maison des technologies Toulon 83000, France thierry.soriano@supmeca.fr Abstract – In this paper we present a contribution to SysML for energy interchange depiction. This contribution consists of an extension to the activity diagram. We mapped it to the Bond Graph formalism which is often used for the design of mechatronic systems. We use the extension mechanisms that SysML inherits from UML2.0 such as stereotypes and tagged values to establish mapping rules from activities to bond graphs. The paper is concluded by an example to illustrate this proposal. Index Terms – Mechatronics, Bond Graphs, SysML, UML 2.0, Activity diagram. I. INTRODUCTION The system approach is essential to deal with complex systems such as mechatronic systems. It is a global multidisciplinary methodological approach that aims at master the practices of systems engineering. SysML [1] is an essay to provide systems engineers with a standard language that covers the specification, analysis, design, verification and validation phases. Bond Graphs are used to depict the energetic transfers between subsystems of different natures (mechanical, electrical, hydraulic…). It is today used in numerous important projects inside companies such as PSA, Renault, General Motors…[5] The SysML language as it is defined in its current version doesn’t enable users to use this powerful tool of analysis, simulation and dimensioning that is the Bond Graph formalism. In this work we are presenting one possibility to integrate Bond Graphs into SysML using SysML constructs or in the worst case UML 2.0 constructs [3]. In the second section we will introduce SysML. Then we will present the Bond Graph formalism. In the fourth is a detailed presentation of our contribution. Then we give an example. Finally we give some conclusions and perspectives of this ongoing work. II. SYSML PRESENTATION SysML is the Systems Modeling Language built as a response to the OMG’s (Object Management Group) UML for systems engineering request for proposal [2]. This proposal claims that systems engineers need a standard language easy to integrate both in the engineering teams and in the existing tools. It asserts that the language must help heterogeneous teams (software, electronics, mechanics…) to work together and understand each other. This is why SysML is based on the minimal subset of UML2.0 that satisfies systems engineers needs. It is intended to be minimal to be easily accepted by the systems engineering community. In addition to that SysML is an extension to UML2.0 and tries to bring the minimum change to the UML metamodel to facilitate its implementation to tool vendors. It benefits from the UML extension mechanisms (stereotypes, tagged values). In the “UML 2.0 infrastructure specification” [4] a stereotype “defines how an existing metaclass (or stereotype) may be extended, and enables the use of platform or domain specific terminology” [UML infrastructure page 174]. These mechanisms will be used to specialise SysML to specific domains such as aeronautics, automobile etc. SysML is also aligned with other standards such as ISO AP-233 [8] for data exchange to support tool interoperability. SysML also inherits the XMI (XML model interchange) from UML2.0. But this minimal SysML or lets say this basic SysML will need to bring to these systems engineers their usual tools by creating extension packages that can be added or removed from their design environment just like the practices of the software engineers with the profiles of JAVA, C++, CORBA and much others. This is why we think that we need to build these extensions for the basic SysML. The activity diagram is already used to express EFFBD’s (Enhanced Functional Flow Block Diagrams). These EFFBD’s are usually used by systems engineers. Bond Graphs are also usually used by systems engineers. In [11] W. Borutzky establishes a relationship between Bond Graphs and object-oriented modelling. In this paper, we are presenting their application using SysML. The Bond Graph formalism is quickly presented in the following. III. BOND GRAPHS SUMMARY Modelling a mechatronic system often needs the description of the energetic transfers between subsystems. In addition a homogenisation of such a description must be accomplished to visualize on the same diagram a phenomenological analysis of the system. This is done by the Bond Graph formalism that allows in the same time to discover the system’s equations, which are used for the simulation and the dimensioning. There are three levels of Bond Graphs representation [6]. The first level is the word-Bond Graph that is used to have a first approach in describing the energy map of the system and its composition. The second level is the Acausal Bond Graphs used to show the energetic transfers by representing each subsystem by its energetic function assuming that the decomposition is advanced enough so that we can replace each subsystem by an elementary component. These elementary components will be defined later. The third level is that of the assignment of the causality which helps finding the system’s equations; it is the causal Bond Graph. Causality is represented by a vertical line on the energetic arrows. This concept has nothing to do with the causality concept used in systems theory. The set of the language constructs of the third level contains all the necessary constructs to build any of the three Bond Graph types. A subsystem is represented by a closed line with a name. This line represents the frontiers of the subsystem. For each energy interchange of the system with its environment we associate to it an energetic port of a defined type (mechanical energy, electrical energy, etc…). A unidirectional semi headed arrow shows the energy interchange throw this port and carries the data relative to the power transported (e: effort and f: flow). These two variables are necessary and sufficient to describe the energetic transfers inside the system. They correspond to a couple of variables in each energetic domain. (tab 1) TABLE 2 BOND GRAPH ELEMENTARY COMPONENTS Active elements Flow generation. Passive elements Energie dissipation node. Effort storage node Flow storage node. Sensors Flow sensor. Effort sensor. Conversion elements Energy transformation implying : Energy transformation implying B. The junctions Junctions (tab 3) are used to associate those elementary components. They transmit the energy instantaneously. They must co nnect a number of arrows higher than 1. TABLE 3 THE TWO KINDS OF JUNCTIONS TABLE 1 THE EFFORT AND THE FLOW IN DIFFERENT ENERGETIC DOMAINS. Energetic domain Translational mechanics Rotational mechanics Electricity Effort e Flow f Force Velocity Torque Angular velocity Voltage Current Hydraulic Pressure Volume flow rate Thermal Temperature Entropy change rate Pressure Volume change rate Magneto-motive force Magnetic flow Magnetic Effort generation. A. Elementary components or nodes The elementary components/subsystems are classified (tab 2) by their energetic behaviour (energy dissipation, energy storage…) and their function inside the system (flow sensor..). In this proposal we use the Bond Graphs notation described in [9] where only TF and GY are extended to modulated elements (MTf and MGy). We don’t map mixed elements such as IC, IR or RC. De and Df are used to represent sensors that do not consume power (ideal sensors). Jonction 0 : all efforts are equal Ex: Parallel connection in electrics. f 1+ f 2 − f 3 = 0 e2 = e1 = e3 Jonction 1 : all flows are equal Ex : Series connection in electrics. f1= f 2= f 3 e1 − e2 − e3 = 0 C. The arrows or bonds In Bond Graphs there are two types of bonds (Tab 4). The first shows an informational transfer and the second shows an energetic transfer. The first one is represented by a full headed unidirectional arrow. The second, by a semi-headed unidirectional arrow that are assigned a number for identification. In addition to this, in the case of a causal Bond Graph, a vertical line is added on one of the extremities of the arrow. This causal stroke indicates the direction in which the effort bond is directed which is the opposite of the direction of the flow ([9] pg 25). very general constructs, it also doesn’t have control nodes which is useful to depict junctions. TABLE 4 BOND GRAPH BONDS/ARROWS Energetic transfer Without causality With causality Informational transfer IV. MAPPING TO SYSML/UML2.0 CONSTRUCTS A. Candidate diagrams It is important to choose a diagram that will be easily recognisable as a Bond Graph diagram to limit the learning effort of systems engineers. In the other hand, it is essential to respect the semantics of the UML diagrams. For example, a final state in a UML statechart is defined as a state that cannot have a state activity (no DoActivity attribute [UML superstructure page 462]). This constraint must be respected for any extension added to the original diagram. In SysML the diagrams used to describe behaviour are: Use cases, interaction diagrams, parametric constraints diagram, statecharts and activity diagrams. Use cases cannot express control nodes and are used to express top level system requirements. They cannot express energy or information transfer. Interactions are to be avoided because of the life line representation of objects which is too much far from Bond Graphs. Parametric constraints are used to associate objects properties to express mathematical relations between physical variables which may be useful when we’ll need to extract the system’s equations. It is not useful at this stage. Statecharts can only represent control flow and not object flow. Activity diagrams are the most appropriate view because they use constructs that express object transfers and control between actions. They combine system’s composition (in term of actions executed) with communication and sequencing between these actions. It can be useful to compare this proposal with a representation of Bond Graphs that uses diagram assemblies. They may also be considered as an alternative. In fact, they depict a system as a collection of components with specific roles. They also show connections between subsystems inside the hole system ([1] page 49). It seems that the assembly diagram is closer to Bond Graphs than activity diagrams. In fact assemblies are used to depict the system’s composition in a static way. This is the opposite of activity diagrams that are intended to depict a sequence of actions. Of course we can “just not take into account” this actions sequencing, but there is still a risk of misunderstanding of Bond Graphs when expressed by activity diagrams. It is clearly not natural for a systems engineer to use activities one time for sequencing and the other time for a static representation. In the other hand the assembly diagram is composed of B. Mapping Bond Graphs to activity diagrams 1) Elementary components or nodes: We use the « Action » construct to represent nodes that have an energetic function. In Bond Graph formalism, systems are decomposed until we obtain subsystems that can be assimilated to an elementary-energetic phenomenon represented by one of the nodes described in the Bond Graph introduction paragraph. We can then assimilate an elementary subsystem to an action as it is defined in the UML 2.0 specification: It is the fundamental element of behaviour specification. It accepts a set of inputs and converts it into a set of output.”[UML Spec: Def ACTIONS page 203] An Action is defined as an abstract class. Then we have to inherit from it. We must remember that one of the advantages of SysML is that it will benefit from UML tools. This is why we cannot introduce contradictions between the SysML meta-model and the meta-model of UML2.0. Fig 1. Fig1.SysML : Profile of UML2.0 or new meta-model. In order to respect this constraint we can use two different solutions. First, we can add another child class to Action (Fig 2) and call it BondGraphAction. Second we can use one of the existing child actions and map it to a Bond Graph node. Fig 2. Adding a child class to Action in the meta-model. The UML meta-model is usually not open source. The second solution seems then to be more easily realisable. This is why we use the ApplyFunctionAction meta-class to represent a Bond Graph action. ApplyFunctionAction is composed of a set of inputs, a set of outputs, and is associated to a function. Fig 3. (UML superstructure specification [3] page 207). Fig 5. Mapping solution adopted using stereotypes. 2) Junctions: The usage of the Bond Graph junctions correspond to the control nodes in the activity diagram. In the meta-model, control nodes inherit from the abstract class ControlNode. To represent the two junctions of BGs that are junction 0 and junction 1, we have to inherit two new nodes of control Fig 6, 7. Fig3. ApplyFunctionAction’s meta-model. An ApplyFunctionAction is defined [UML specification page 222] as an action that invokes a predefined function that uses inputs to compute outputs. To use ApplyFunctionAction we can use the inherited attribute “effect” [UML specification page 280] that is defined as being a description of the function executed by the action. But as in our case the number of possible functions is limited, the most appropriate solution is to specialize ApplyFunctionAction for each function. But we do not use an inheritance of classes, we use stereotypes. Stereotypes are used to add semantics to a metaclass. Its advantage is that it is accessible in the UML tools. In this Fig 4 we show the stereotypes created for the Bond Graph elements. The inheritance arrow used is full-headed to express extension on the meta-model, see [UML infrastructure page 167]. Fig 6. ControlNode hierachy Fig 7. ControlNode notations We can also use together the decision node and the merge node represented by a diamond for both junction 0 and junction 1. This can be done by stereotyping those nodes Fig 8. In fact the merge node and decision node can be used in the same diagram element[UML superstructure specification page 344]. This is the better solution because it prevents us from accessing the metamodel, we just use the extension mechanisms. In Fig 8, we use a Bgraph_junction abstract class to inherit from both MergeNode and DecisionNode. Then we stereotype this node to BG_0 and BG_1. Both resulting nodes will be drawn using the diamond. Fig 4 .ApplyFunctionAction stereotypes. This way we can express on the same diagram, the three levels of Bond Graphs for better understanding. We can also use the PrimitiveFunction object Fig 3, to express the mathematic formula that goes with the element. This formula can be used later for system’s equations generation. In Fig 5 we show an example of application. Fig 8. Bond Graph nodes hierarchy. 3) The edges or bonds: Two different edges are defined. We use the stereotypes/tagged values mechanism to define these child classes of the UML 2.0 ObjectFlow class. The black arrow in Fig 9 says it is an extension to the metaclass ObjectFlow. The attributes of the new defined classes are also called tagged values. The causality attribute/tagged value is of type CausalityType which is an enumeration (start, end, nonCausal). read in page 355 that OutputPins are used with an annotation text {steam} to show streaming (or the little black square Fig 10) and has attributes that can express exceptions and parameter sets. So there are two ways to express streaming for object nodes. This is probably a redundancy in UML2.0. Fig 12. ActivityParameterNode use of the Parameter construct Fig 9. ObjectFlow stereotypes for Bond Graphs. The energetic transfer is done through an energetic port in BGs. They are represented by pins Fig 10 Fig 10. Energy bond representation. Object flow of activity diagrams in UML 2.0 cannot associate two actions directly. This is why we use pins. Pin is an abstract class, so we use OutputPin or InputPin. In our case they are shown as black little squares to express that it is a streaming port. This means that the isStream attribute is set to True and consequently, the isException attribute is set to False Fig 11. 4) Constraints on the defined elements: For each element a list of constraints need to be defined so that we can express correct bond graphs with this extension. As an example we present here the constraints that come from the causality concept used in bond graphs: -Junction 0: Only one causality sign close to the junction. (sum(causality=end of entering flows),(causality=start for leaving flows))=1. -Junction 1: Only one EnergeticFlow whitout a causality signs next to the junction (sum(causality=end of entering flows),(causality=start for leaving flows))=number of flows-1. -De,Df : No causality (ideal sensors) De can only be connected to 0-junction. Df can only be connected to 1junction. -EnergeticFlow from an Se element: causality=end. -EnergeticFlow from an Sf element: causality=start. -Tf element: Both EnergeticFlows with causality=start Or both EnergeticFlows with causality=End. -Gy element: One EnergeticFlow with causality=end, the other causality=start. 5) Block diagram extension In order to use this BG representation, we need to add the elements that correspond to the Block Diagram elements. In fact, block diagram is used conjointly with BGs to depict the control part of the system. Fig 11. Pins hierarchy. In the “UML 2.0 superstructure specification” [1] page 352 we can read “Parameters are extended in Fig 13. Block diagram extensions. complete activities to add support for streaming, exceptions, and parameter sets”. A specific ObjectNode V. FORMALISM APPLICATION called ActivityParameterNode is defined to use this parameter (Fig 12) so that an ObjectNode can support In this section we are showing an example of usage of streaminf, exceptions and parameter sets. We can also our activity-bond graph. We describe this simple servo system (Fig 14) with causal bond graphs then with the SysML activity bond graphs. VI. CONCLUSION The activity diagrams are a good formalism to express Bond Graphs. The extensions that are necessary for activities to comply with Bond Graphs are not heavy. We only used classical extension mechanisms such as stereotypes, tagged values and constraints to define this activities extension. This is why SysML users can easily Fig 14. Word-bond graph/Block diagram of the system integrate Bond Graphs to their design environment be it used as example. rational rose, objecteering, rhapsody, Poseidon or any The resulting causal bond graph representation is other tool that supports usual extension mechanisms shown in the following Fig 15. The control sub-system is which is a considered as a basic feature of CASE tools a block diagram, we only map the physical sub-system (Computer-Aided Software Engineering Environments). with the activity diagram. VII. PERSPECTIVES Fig 15. Associated Bond Graph. This causal bond graph will be represented in SysML by Fig 16. The flow number 4 is described as an energetic flow stereotyped Bgraph_EnergeticFlow. Its causality is set to the end position and its energetic domain is set to electricity which is one of the values of energeticDomainType enumeration. Fig 16. Activity representation of the system. We depict in the following diagram Fig 17 the specification of two bonds. Bond number 1 and bond number 10. The first one is an energeticFlow and the second is an informationalFlow. Fig 17. Specification of diagram elements. The Bond Graphs/Block diagrams composition can combine the command part with the physical part of the system. This can be an important extension to SysML that may be an argument to convince systems engineers to use this language that wants to be the de facto standard. One of the advantages of bond graphs is that it can be used to extract the system equations to be simulated. We could generate these equations from our activity diagram and describe them using the parametric diagram included in SysML. We can also use other simulation tools. One possibility is the generation of Modelica code. Modelica is an object-oriented modelling language with a textual definition to describe physical systems. A Bond Graph library was written in Modelica. In addition to that, Modelica code was generated from Bond Graphs [7, 10]. We need to continuously keep this proposal up to date as both UML 2.0 and SysML specifications are still evolving. We are expecting a new version of SysML to be released by the end of 2005. REFERENCES [1] SysML specification V0.9. 10 january 2005. [2] UML for systems engineering RFP, OMG Document: ad/03-03-41. [3] UML 2.0 Superstructure Draft Adopted Specification. OMG Adopted Specification ptc/03-08-02. [4] UML 2.0 infrastructure specification, OMG Adopted Specification ptc/03-09-15. [5] G.Gandanegara, « Méthodologie de conception systémique en Génie Electrique à l'aide de l’outil Bond Graph Application à une chaîne de traction ferroviaire », PhD report for the « Institut National Polytechnique de Toulouse», page 5, 2003. [6] J. Zaytoon, “Systèmes dynamiques Hybrides”, page 94, 2001. [7] J.F. Broenink,, “Object-oriented modelling with bond graphs and modelica”. International conference on bond graph modelling ICBGM’99, Simulation series Vol 31 no 1,SCS, page 163-168. [8] I. Bailey, F. Dandashi, H. Ang, D. Hardy, “Using Systems Engineering Standards In an Architecture Framework”, white paper eurostep company. [9] D.C. Karnopp, D.L.Margolis, R.C.Rosenberg, “System dynamics – Modeling and Simulation of Mechatronic Systems”, third edition 2000. [10] W.Borutzky, “Object-oriented Modeling of Mechatronic Systems Using Bond Graphs”, proceedings of the IASTED international conference in Applied Modelling and Simulation, September 1999. [11] W.Borutzky, Relations between graph based and object-oriented physical systems modelling, ICBGM’99 International Conference on Bond Graph Modelling and Simulation, San Fransisco, CA, Jan. 17-20, 1999, pp.11-17.