Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - PDC

Pages: [1] 2 3 ... 5
Apologies for resurrecting an old topic but I have this exact same problem (build 1628).
In my profile's toolboxes the Elements/Relationships are ordered in a particular way, but when the ViewSpecification Exposes those Elements/Relationships they are all just lumped into one toolbox in alphabetical order. The View Specification doesn't seem to be able to Expose the toolbox itself either, which is a shame.

It's not the most significant problem in the world (all the tools are available in the View, just in a funny order) but if there is a way to achieve this I would greatly appreciate knowing please :)

Uml Process / Re: Modeling Calls between operations
« on: June 18, 2024, 06:20:08 pm »
There are a few ways to model behavior. Sequence diagram and Activity diagrams are the suited for this.

I don't think it's a good idea to try and mix structure and behavior aspects into one diagram...

ownership in EA is not expressed in diagrams at all, unless you create a nesting connector yourself

(slightly off-topic...)
Really good points. I often find that Allocate is useful here too.
Stakeholders/Managers etc often want the 'everything-on-one-page' view, but as Systems Engineers we still need to educate that SysML serves a particular purpose, and 'bending the rules' is sometimes useful but often just adds confusion. It's one of the big benefits and also big pitfalls of EA - it's super flexible and lets you bend the rules a bit, but we do have to be careful that what we end up with is still correct and meaningful (especially when we need the model to do even basic things for us like checking traceability, consistency, design queries, simulations....)

Uml Process / Re: Modeling Calls between operations
« on: June 14, 2024, 05:45:52 pm »
I assume you are using a Sequence Diagram. In which case it doesn't really make sense to represent Operations as lifelines. Lifelines are intended to be typed by a Classifer, and I think the UML spec is restrictive that those classifiers do not (cannot) include Operation as a classifier for the lifeline. That semantic distinction is probably why SysML tools (like EA) don't support what you are trying to show (Operations as lifelines) and is probably why you're struggling to get it to represent that way.

One solution could be to model your Operations as Classes (Blocks) and then you will be able to have lifelines that represent your Operations. You'd need some kind of Relationship between your 'Operation' pseudo-Block and the actual Block that owns the associated Operation... but it probably also depends on exactly what you are trying to communicate, who you are communicating to and how bothered they are about syntax & semantics.

General Board / Re: EA 17 Beta install removed my EA 16
« on: June 07, 2024, 05:40:39 pm »
Seem to recall it is possible to have multiple installations if you install in different folders.

Will do some more investigation.


I have 15.2 in [C:\Program Files (x86)] and 16.1 in [C:\ProgramFiles].

PDC, so if I understand your response correctly, that means then that blocks own properties representing the data items that are transmitted/received. So for example a block owns a property called Gasoline, typed by something like Liquid. It owns another property called Water also typed by Liquid. As we create the ports and connections, we relate the ItemProperties to the Properties of the owning blocks and that is what makes it clear to the reader where the information is going.

FlowProperties are owned by an InterfaceBlock.
FlowProperties are typed by a Classifier.
The Blocks in the design have Ports that are typed by the InterfaceBlock.

So one way (probably not the only way) to model our gasoline scenario could be: 'InterfaceBlock1' owns an incoming Flowproperty called 'gas-in' which is typed by a Classifer 'Gasoline'. And the Classifier 'Gasoline' may be a Generalization of another Classifier 'Liquid' (purely to support definition of other subtypes of liquid). Then there are multiple Blocks that have Ports, and the Ports are typed by 'InterfaceBlock1'. The Ports are connected (on an IBD) by InformationFlows, for which we use the 'Information Items Conveyed' context menu to add Information Items typed by the 'Gasoline' classifier.

All of that produces an IBD consistent with the Distiller one in your latest post (saves me working out how to upload screenshots :) )
It looks like the Distiller example uses Blocks ('H2O', 'Heat', 'Residue' & 'Fluid') to type the Ports, rather than InterfaceBlocks. This seems kind of a little naughty to me but there may be good reasons for doing so that I'm not aware of.

I am defining a SysML profile using the metamodel tools.
I've defined a bespoke Stereotype that extends the metaclass 'Port' (let's call it 'PortNew').
I've defined a bespoke Stereotype of the metaclass InterfaceBlock using a Generalization (let's call it 'IFNew').
I've added 'PortNew' to a new toolbox and can add it to Blocks on a BDD. However, I want to be able to set up the profile so that any time I add a 'PortNew' to a Block it uses IFNew as the Port's interface definition - i.e. as 'Type' under the Port Element Attributes.

Is this possible? I can't figure out how to set it up in the metamodel.

I am afraid my understanding is not correct, so please tell me if my post is wrong.

No I totally agree with everything you said there (I wrote a long response explaining that I agree, and then my network went down as I pressed 'Post' so it was lost. But you are correct!)

After posting my previous post I continued playing around and found that EA was behaving inconsistently. Actions like restarting EA or opening/closing different Element properties was affecting the display of the labels on the diagram. I do agree that it is strange that it lets me set the InterfaceBlock FlowProperty as the itemProperty on the ItemFlow... maybe that's where I had managed to confuse EA into showing something that it shouldn't.

General Board / Re: Inheriting Signal attributes
« on: May 14, 2024, 12:55:30 am »
Right-click on s2, choose 'Compartment Visibility' and select 'Inherited Attributes'. The inherited Attribute will then be displayed.

Do you need to be able to manipulate that variable from s2?

Excellent summary, thanks. And that is how it worked out in my case as well.

No problem... although I have to admit that now I go back into my sandbox area it is rendered as "Water {Water}", not "Water: Water". I think this is purely a graphical thing though and the underlying semantics are equivalent. Water/water... Potato/Tomato...

I just have this one last theoretical question regarding the InterfaceBlock. If in my case I have different messages all of the same type, then I think the flow properties need to be on the owning block, and not in the InterfaceBlock. Suppose you had two messages of type CAN: speed, torque. Then I would have two ports typed by an InterfaceBlock called CAN. If I have the flow properties on the InterfaceBlock, then anytime I type a port with a CAN InterfaceBlock, it will have both properties and I want to avoid that, which makes me think perhaps the block has to own the flow properties. The InterfaceBlock would have just the common information.

Personally I wouldn't worry about this. For one thing, I don't think Blocks *can* own FlowProperties - they have to belong to the InterfaceBlocks.
At the same time, the InterfaceBlock defines what is permissible to flow across that interface, as a static representation of the interface agreement between 2 entities. You then use the rest of the model to describe what actually does pass over that connection in different circumstances. So you might know that it is an RJ45 connector, and there is an almost infinite number of different information items that 'could' be sent over that interface, but you use the IBDs to give context for a particular scenario, and use logical modelling to describe how the InterfaceBlock decides what is sent (e.g. an Activity Diagram that illustrates a choice, like "if a data packet of type packetA is received from the internal Block, then send out a packet of type 'packetB' on the external connection").
I guess it all depends on what your model is trying to communicate though

Think I understand the question a bit better now.
I think the following steps give a semantically-similar result.
This includes all steps to build an ICD.

1. create the data definitions (e.g. define 'Liquid' and 'Water' as Blocks, with 'Water' as a Generlization of 'Liquid')
2. create an InterfaceBlock with a FlowProperty that represents the data items permitted to pass over that interface (e.g. a FlowProperty called 'Water' that is typed by the 'Liquid' Block, or another FlowProperty called 'gasoline' that is typed by the 'Liquid' Block)
3. add Ports to your Structural Blocks and classify them using the InterfaceBlock (helps give your ICD meaning)
4. draw the ItemFlow between the Ports and add an InformationItem typed by the 'Water' Block and 'itemProperty' tagged value set to be the flowProperty defined within your InterfaceBlock definition
5. draw a Connector between the Ports and link it to the ItemFlows relevant to a particular context*

What you should see on the ItemFlow/Connector is "Water: Liquid"

* on another diagram, you might have an ItemFlow carrying the 'Gasoline' data item, which would be rendered "Gasoline: Liquid". This lets you should the same connection with different flows for different scenarios/contexts

Suppose I have 10 signals like CAN messages for example, that are sent from one block to another. All are signals of the same type (CAN).
Do I model 1 block of type CAN and then create multiple item flows using that same type?
Or do I create 10 CAN blocks for example, each with a different name and then refer to them in the item flows?

You *can* (no pun intended) do either, but personally I would do the first option. Define 'CAN signal' as a Block and use it as the Classifier to type the data items flowing around your system. That way you can add generic descriptions to the classifier and only have to do it once. And it's applied consistently throughout. YOu can also do this using just one itemflow and attach all 10 CAN data items to that one flow, although this assumes some semantics... e.g. that all of the 10 items generally flow across that link in the same scenario. If there are different scenarios then multiple data flows would help you illustrate the specific data flows in each case.
If you need to create a hierarchy then that could be useful (e.g. if all 10 signals are broadly the same, but then 5 of them have some special characteristic that the other 5 don't).

Hope some of that helps... though it's probably easier to illustrate my points graphically rather than English-ly.

In the book by Friedenthal, Practical SysML there was an example of using flows of electricity (DC). The notation used there I could not get in EA:
azm supply : DC
fm supply : DC
elm supply : DC
I suspect the DC is of course a block, but the names to the left I cannot figure out how to do in EA. The reason I am confused is because a block represents a type, so I have doubts about creating 10 CAN blocks when all are of the same type. In EA however, I can't seem to distinguish them. All 10 connections just show CAN.

Can't be 100% sure without seeing the notation (I don't have the book) but it looks like 'DC' is a single classifier (a Block) and then 'azm supply' et al are the names of instances of that classifier.

General Board / Re: Removing a linked document in v16.1.1628
« on: May 09, 2024, 11:59:13 pm »
Here's one way:

1. select the Element that has the Linked Document
2. on the ribbon, go to 'Portals > Windows'
3. select 'Document' under 'Properties'
4. the 'Document' window should now appear (somewhere)
5. use the hamburger icon and select 'Delete Linked Document'

General Board / Re: Modeling interfaces in SysML
« on: May 09, 2024, 06:32:16 pm »
For me it partly depends on the requirements for your model. i.e. do your stakeholders need you to be able to present the logical view and the physical layers separately? In that case, it is normally going to be easier to model both Ports separately and, as you suggest, draw the traceability between them - e.g. using 'Allocate'. However, if your stakeholders are less bothered about that (or don't understand the question) then maybe you can [cut some corners and] somehow model both layers using a single Port. My personal preference is to keep the functional, logical and physical views separate in the model - so I would have a logical Port and a physical Port in your scenario.

I also sometimes find that 'nested' Ports are useful in this context.

You mention the 'literature' - maybe you have already read this paper but I think it's a good discussion on a related subject:

Sounds like a reasonable way of mapping it to me. As long as it works for you then it's not worth getting overly bogged down in SysML semantics.
I did wonder if there might be a way for you to attach your Blocks to the State transitions in the STM - i.e. "in order to get from StateA to StateB, Block1 must be added to the build". But I've not played around with it myself. Probably several ways to do what you're trying to do if you aren't too worried about semantics.

If you use the profile helper, you can simply fill in fields like MeaningForwards and MeaningBackwards. The tool will automatically create the attributes with the correct name on the correct item.


This is how I solved it - had avoided the profile 'helper' based on previous misconceptions but in this instance it actually did prove very helpful! Egg on my face.

Cheers :)

Pages: [1] 2 3 ... 5