sysml | Systems Engineering Modeling Language domain

Yes by definition an actor is external to the system they react with, then all depends on what the system is, this is a matter of perspective

I was wondering if I should use the sensors as a system, and use the already existing system as a secondary actor?

exactly, when the system you describe is your sensors the already existing ones are out of it and they can be represented as actor, and even as primary actor if they activate your use cases.

If you describe the already existing sensors the roles are reversed and your sensors becomes actor

[edit from your remark]

If the overall system includes the already existing system and your sensors, the already existing system becomes a sub system of the overall system, and your sensors is also a sub system of the overall system.

When you describe your sub system, the sensors from the already existing sub system can be still actor etc, nothing change. A sub system is a system.

A block definition diagram is usually not used to show the flows between components of your system. Instead you would use an internal block diagram of your system with the two parts s:Supervisor and c:Controller.

To specify that the controller provides the operation set_reference(r:float) you would use an InterfaceBlock as Type of a port of the controller. The same InterfaceBlock would be used as Type of a port of the supervisor. This time, however, conjugated. That will be shown by prepending a ~ symbol. Then you need to connect them via their ports. This already suffices to specify that a float value can flow across the connector. Nothing else is needed.

However, sometimes you didn't decide yet, how to realize the flow (there is more than one possibility. The set_reference operation, as you have done it, a get_reference operation provided by supervisor or a flow property). So, you only want to specify the need for some item flowing, but not the mechanism. In this case you could leave the ports without a type and model an ItemFlow across the connector. It would be shown with a filled triangle placed somewhere near the center of the connector and labeled with the name and type of the flowing item. A tool could even support you, by later creating the InterfaceBlocks and operations automatically.

As I said, if you already know, how you are going to realize the flow, modeling the ItemFlow is redundant. Except of course, if you want to limit the possible values in your specific system. Lets say, double is a specific float, and in your system only doubles will be used, even though the controller could also handle singles. This can be expressed with an ItemFlow of Type double.

Some people prefer to only model ItemFlows and leave out the connectors. ItemFlows alone are shown as dashed arrows with the keyword «flow». I advise against this, because ItemFlows don't imply that the parts are connected (the flow could be realized by intermediary elements).

It is not possible to import a random xml file into EA, not even if you have imported it's XML schema.

There are a number of file formats supported such as XMI, EMX/UML2, etc... but URDF is not one of them.

So in order to import the file you'll have to write your own automation in the form of a script, add-in or standalone program.

Before you can do that you'll have to determine how to translate your URDF file into EA concepts such as elements, attributes, connectors or tagged values.

Look here for more info on automation in EA: https://www.sparxsystems.com/enterprise_architect_user_guide/15.2/automation/automation_interface.html

In UML and SysML state machines, reaching a termination pseudo state means that the scope to which the behaviour that is defined by the state machine is terminated (when it is on the top scope in the state machine diagram). This is treated in different tools diffently. Some tools use (by default or always) the state machines as mester for simulation and when the topmost state machine enters a termination pseudo state the simulation is stoped, even if it was triggered from an activity.

There is a further kind of end pseudo state for state machines, it is called an exit point. Exit points trigger that the current scope is left. And as you dont want to stop your simulation this is waht you could use. An exit point is denoted by a hallow circle with cross.

Thought: Plenty of tools deviate from whats defined in UML and SysML especially when simulating dynamic behaviours. So there might be some special options in Cameo that possibly need some consideration. One solution to some of the tools is that you create a master state machine, that triggers your master activity.

for me the output pin result of the value specification corresponding to your instance must be linked to the input port object of a Read Structural Feature Action whose have test as structuralFeature and its output port result is linked to the decision node.

The output port of the value specification values your instance, not the value of test for it

The MagicDraw Developers Guide (currently for v19.0-SP2) has information on their OpenAPI, which supports Jython, which is a Java implementation of Python.

The OpenAPI implementation allows writing scripts for MagicDraw that can be called from any MagicDraw Query (for example, expressions in table scopes, table custom column definitions, and queries in Legend Adornments).

There is information on Jython scripting here in the OpenAPI documentation.

The core Python development is CPython, which is primarily in C and compiles to given targets like C. The Jython port is compatible with Java and targets the Java JVM rather than compiling for a particular platform.

This allows running a Jython interpreter for Python as a class object directly in Java, and writing Jython scripts that run on the JVM directly.

Jython currently only supports Python 2.7. There has been development of Jython for Python 3.5 under development in the past, though it is "resting" at the moment, as stated in this SO answer

Though SysML is targeted on modeling hardware, it is using similar language elements like UML. And of course it can model hard- and software - like UML.

Actually you can (almost) show SysML using a profile in UML. You can find both the SysML spec and the UML profile at https://www.omg.org/spec/SysML/1.2/About-SysML/

You should not be afraid to use UML if it's at hand. You can describe anything (technical) using this language.

RE your edit (this might start going to far, so if anything else arises ask a new question):

• Cooling should be a class of its own. You'd have some abstract cooling device which can do general cooling (of the attached device). You then use specialized coolings that can do more (or less) fancy stuff. An ice bucket would be a simple one. And a Linde machine could come with lots of additional features.

• That with the levels seems ok. Note that there's a naming convention where you start classes with upper and attributes/operations with lower case. So one back you'd better write cooling: Cooling

• About the memory. The way you did it is not good. It's not overriding anything in that case. Also memory as a general attribute sounds like a flawed design. Memory is too general. Think about what kind of settings should be allowed and probably put these in an enumeration. That definitely needs a bit of brain power to get it right.

As said, these are a few loose thoughts. Making a design is good for an afternoons workshop (as a start).

Use a key to lookup the node names - for example:

XSLT 1.0

If your script refers to xmi namespace, it must be included in the main element of the script. So stylesheet must contain xmlns:xmi="...".

Below you have an example script. I added also xsl:output to switch the indentation on and xsl:strip-space to filter out unnecessary spaces.