Professional Documents
Culture Documents
1 14
http://etherpad.osuosl.org/iTWOivoWSZ
http://wiki.project.scilab.org/AGESYS
Each block can be connected to each other with two different kinds of link.
Event links connect to red ports. Event ports are represented by an arrow which could have an "in" or "out" direction.
Data links connect to black ports. Data ports are represented either by an arrow either by a square box. They could have either
"in" or "out" or "inout" direction.
Here is an example of a block with one event input and two data inputs:
When double-clicking on the superblock, here is the diagram we can see. One must bear in mind, in this case, the superblock Xcos
diagram has one input block and one output block. It should be aligned in the upper diagram with the super block which have one input
data port and one output data port.
https://wiki.scilab.org/Xcos/SysML?action=print
12/1/2017
2 14
Most of the blocks can accept user-defined values. For example, the clock block has the following parameters:
For storing user defined values and other values needed for the simulation, every Xcos block has internal parameters. In Xcos format,
these parameters are represented by either string matrices, float matrices or integer matrices.
Finally, every Xcos simulation has parameters to set the beginning time, the end time and tolerances of the simulation. In Xcos editor,
you can access these parameters via the menu "Simulation" / "Setup". Here is a snapshot of the simulation dialog:
In Xcos editor, you can specify the context of the diagram. By setting the context, we mean variable initialization for instance. This is
accessible by selecting the menu "Simulation" / "Set Context". Here is a snapshot:
When debugging Xcos simulation, it could be useful to generate debug information. This is accessible via the menu "Simulation" /
"Execution Trace And Debug". Here is a snapshot of the dialog window:
https://wiki.scilab.org/Xcos/SysML?action=print
12/1/2017
3 14
Mapping from Xcos diagrams to SysML using block definition diagrams and
internal block diagrams
Mapping between the main Xcos Diagram and SysML
Block Definition Diagram
As explained on the SysML specification, the Block Definition Diagram in SysML defines features of blocks and relationships between
blocks such as associations, generalizations, and dependencies. It captures the definition of blocks in terms of properties and
operations, and relationships such as a system hierarchy or a system classification tree.
Here is the equivalent block definition diagram edited in Papyrus which represents the Xcos "Water Tank" demonstration. This is a
fisrt step mapping. This diagram is not final and is an intermediate one. All the Xcos information are not present in this papyrus
diagram.
As you can see, the block definition diagram is composed of eleven SysML blocks.
Each block has internal properties which represent the main internal Xcos block parameters.
You can also remark that each block has some flow ports which describe the connection between each other. You can distinguish
between event flow ports and data flow ports.
You can also notice that links between SysML blocks are not drawen. This is because roles between simulation blocks are in fact
described in an internal block diagram.
Each block in Xcos diagram has internal properties. Each parameter of an Xcos block will be mapped within a block property. Here is
the example of the CONST_m Xcos block mapped with all its properties in SysML.
https://wiki.scilab.org/Xcos/SysML?action=print
12/1/2017
4 14
In Papyrus, the simulation information such as the context, the solvers, etc should be modelised by a parent block. This parent block
should have properties which describes these information needed for simulation:
Here is the final block definition diagram of the main Scilab/Xcos diagram. In this diagram, we can see that the parent block is
composed of all the simulation blocks.
8.3.2.2 Block::isEncapsulated
If true, then the block is treated as a black box; a part typed by this black box can only be connected via its ports or directly to its
outer boundary. If false, or if a value is not present, then connections can be established to elements of its internal structure via
deep-nested connector ends.
The block is treated as a black box, so always set it true for blocks with a native implementation. For super-blocks ones, set
isEncapsulated=false and provide the implementation as internal block diagram. For mixed implementation, this flag can be used as a
switch to choose the implementation (internal or native one).
Internal Block Diagram
As described in the SysML specification, the Internal Block Diagram in SysML captures the internal structure of a block in terms of
properties and connectors between properties. A block can include properties to specify its values, parts, and references to other blocks.
Here is the equivalent internal block diagram which represents the roles of the blocks between each other.
https://wiki.scilab.org/Xcos/SysML?action=print
12/1/2017
5 14
As you can see, the internal block diagram is composed of eleven SysML parts.
Each parts are connected through their flowports to their corresponding parts by connectors.
Concerning part flowports, when translating an Xcos diagram into a SysML internal block diagram, let's use the following rules:
if data input is concerned, then use "in1" to "inXX" as name of the flow port
if data output is concerned, then use "out1" to "outXX" as name of the flow port
if event input is concerned, then use "ein1" to "einXX" as name of the flow port
if event output is concerned, then use "eout1" to "eoutXX" as name of the flow port
This is a derived attribute (derived from the flow ports type). For a flow port typed by a flow specification the value of this
attribute is False, otherwise the value is True.
By default, this attribute should always be set to True.
9.3.2.2 FlowPort::FlowDirection (SysML 1.2)
Indicates the direction in which an atomic flow port relays its items. If the direction is set to in, then the items are relayed from
an external connector via the flow port into the flow ports owner (or one of its parts). If the direction is set to out, then the
items are relayed from the flow ports owner, via the flow port, through an external connector attached to the flow port. If the
direction is set to inout, then items can flow both ways. By default, the value is inout.
As mentionned in introduction, ports are either event ports or data ports.
Data ports are divided into two sub-categories:
explicit ports. The data which flows on this port is described by explicit differential equation. FlowDirection could be either "in"
or "out". They are represented in Scilab/Xcos diagram by arrows.
implicit ports. This is the modelica behaviour. The data which flows on this port is described by implicit differential equations.
FlowDirection should be "inout". They are represented in Scilab/Xcos diagram by square boxes.
Here is an exemple of explicit ports in an Scilab/Xcos diagram :
https://wiki.scilab.org/Xcos/SysML?action=print
12/1/2017
6 14
When a modelica description is used, Xcos use a modelica compiler to transform the implicit differential equation into a set of explicit
differential equations. The modelica implicit equation description is then replaced by the new explicit differential equations. The
diagram could then be simulated using xcos traditionnal solvers.
For event ports, Flowdirection cannot be "inout". The possible values are only "in" and "out".
Concerning block flow ports, when translating an Xcos diagram into a SysML diagram, let's use the following rules:
if data input is concerned, then use "in1" to "inXX" as name of the flow port
if data output is concerned, then use "out1" to "outXX" as name of the flow port
if event input is concerned, then use "ein1" to "einXX" as name of the flow port
if event output is concerned, then use "eout1" to "eoutXX" as name of the flow port
If set to True, then all the directions of the flow properties specified by the flow specification that types a nonatomic flow port
are relayed in the opposite direction. By default, the value is False.
This attribute should always be set to False.
B.4 Transitioning SysML 1.2 Flow Ports to SysML 1.3 Ports
As explained in annexe B.4, flow ports are deprecated since SysML 1.3. In our case, we will only follow step 1) 2) 4) of the guidelines.
1. Decide if the port should be converted to an proxy port,a full port, or an unstereotyped port.
2. Based on the decision in step 1, create a block (for proxy ports, it must be an interface block specifically).
3. If the original flow port is non-atomic:
a. Copy all the flow properties owned by the flow port's type, a flow specification, to the block created in step 2 (meaning
the flow properties will be owned by the newly created block).
b. Replace the type of the port with the block created in step 2.
c. Remove the flow port stereotype from the port.
d. Based on the decision in step 1, apply the ProxyPort or FullPort stereotype, or do nothing if the decision is not to use
either one.
e. If the proxy stereotype is applied in step 3d, and there is a single connector from the port to a part, the BindingConnector
may be applied to the connector.
f. If the flow specification is not referenced by other model elements, delete it.
4. If the original flow port is atomic:
a. On the block created in step 2, specify a flow property typed by the same type as the flow port and with the same
direction as the original flow port.
b. Do steps b to d from step 3 about non-atomic flow ports.
A superblock diagram has simulation parameters such as its context. As seen in previous section with the main block definition
diagram, these information are stored in a parent block. The relationship between parent block and the simulation blocks is a
composition relationship. Here is the final block definition diagram of the nested superblock diagram.
https://wiki.scilab.org/Xcos/SysML?action=print
12/1/2017
7 14
https://wiki.scilab.org/Xcos/SysML?action=print
12/1/2017
8 14
Under Papyrus, we will use the eannotations of the activity pointed by the call-behaviour item.
https://wiki.scilab.org/Xcos/SysML?action=print
12/1/2017
9 14
if data input is concerned, then use "in1" to "inXX" as name of the argument
if data output is concerned, then use "out1" to "outXX" as name of the result
if event input is concerned, then use "ein1" to "einXX" as name of the argument
if event output is concerned, then use "eout1" to "eoutXX" as name of the result
https://wiki.scilab.org/Xcos/SysML?action=print
12/1/2017
10 14
For such information, we chose to map all these information as EAnnotation of the root activity in Papyrus.
https://wiki.scilab.org/Xcos/SysML?action=print
12/1/2017
11 14
Assuming step 1 is achieved for the w:TotalWeight constraint block, the domain-specific expert imports that SysML block into a
superblock in Xcos (step 2.1). Its first role is to implement this superblock in Xcos. The superblock imported in Xcos has four inputs
and one output.
We can notice that the implementation is coherent with the superblock itself. We can imagine that the domain-specific expert simulates
then the overall system and finds the best parameters that fit its model (step 2.3)
Then in step 3, the system designer imports the xcos diagram in Papyrus, imports the found best parameters values and navigates
through the SysML project.
When the system designer has no idea of what could be an input or output, he can use implicit ports. Here is the same example from the
SysML specification parametric diagram. The system designer is interested by w:TotalWeight but every parameters could be an input
or an output (step 1.1 1.2 1.3). Here is the superblock diagram when imported from SysML (step 2.1) :
The domain-specific expert could implement this nested diagram of the superblock like this :
implicit_superblock_implementation.png
One must bear in mind that Xcos port used for that implementation are square ports. It means they are implicit. There is no given
direction for the data flowing throw these kind of ports.
We have added in next part an optimization process in Scilab/Xcos which could give an idea of optimization process using Scilab /
Xcos.
https://wiki.scilab.org/Xcos/SysML?action=print
12/1/2017
12 14
Here is the modified "Water tank" demonstration used to optimize the Proportional Integral Derivative controler used to regulate the
water tank level.
xcos_demo_watertank_automatic.png
The variable parameters are set in the context of the root diagram P, I, D as shown in the PID user-defined values dialog window.
xcos_PID_window.png
First, we initialize Xcos by loading some important Xcos libraries (done by calling loadXcosLibs()). Then, we load our diagram using
importXcosDiagram.
// load important libs and diagram
loadXcosLibs();
importXcosDiagram('demo_watertank_automatic.xcos');
https://wiki.scilab.org/Xcos/SysML?action=print
12/1/2017
13 14
%scicos_context.I = x(2)*Ifact;
%scicos_context.D = x(3)*Dfact;
Iter = Iter + 1;
Info = scicos_simulate(scs_m,list(),%scicos_context,flag='nw');
y_error = mean(abs((block_output('values')(:,1) - block_output('values')(:,2))));
y_diff = mean(abs(diff(block_output('values')(:,2))));
y = 0.5*y_error + 0.5*1*y_diff; ...
printf('Evaluation %d - P = %f I = %f D = %f y = %f (y_error = %f, y_diff = %f)\n', Iter, x(1), x(2), x(3), y, y_error,
y_diff);
endfunction
For the optim wrapper, we compute the value of the objective function and the gradient (using the Scilab derivative function).
function [f,df,ind] = my_optim_pid(x,ind)
f = f_pid(x);
df = derivative(f_pid,x,h=h_step,order=4);
endfunction
Once these functions are defined, we launch a first simulation to see the initial behavior.
%scicos_context = [];
%scicos_context.P = Pfact*x0(1);
%scicos_context.I = Pfact*x0(2);
%scicos_context.D = Dfact*x0(3);
Info = scicos_simulate(scs_m,list(),%scicos_context,'nw');
Finally, we launch a simulation using the optimized parameters to see the behaviour of the loop.
%scicos_context.P = x_opt(1)*Pfact;
%scicos_context.I = x_opt(2)*Ifact;
%scicos_context.D = x_opt(3)*Dfact;
Info = scicos_simulate(scs_m,list(),%scicos_context);
https://wiki.scilab.org/Xcos/SysML?action=print
12/1/2017
14 14
xcos_optimized_water_level_regulation.png
References
CategoryXcos
https://wiki.scilab.org/Xcos/SysML?action=print
12/1/2017