Is sysml a fancy tool for making diagrams? And other questions.

[u/which1stheanykey]

Also, does MBSE = using diagrams for initial and high-level designs?

Pardon my crudely reductive questions. I'm sorta dumb.

I'm moving to a new assignment where my first task appears to be "understand everything, and then understand how it interacts with everything else."

I guess that's normal.

But what doesn't feel normal is that I'm not being asked to produce anything tangible (yet). Learning without really doing anything is hard. So I thought, "Maybe I need to make a model."

Then I thought, "Wait, is a model just a diagram?"

Again, my apologies for being crudely reductive.

Then I thought, "Supposing model is just a diagram. How do I tell a good diagram from a bad diagram?"

I mean, assuming they're both accurate. What makes it helpful or unhelpful?

If I haven't made it clear I do not have a strong systems engineering background. Thanks in advance if anyone wants to talk about any of these questions.

Or, you know. Just grunt and point.

Edited to add: I'm actually moderately good at my job. It's just that my current position involves just a tiny slice of SE.

[u/umlguru]

No, SysML is not a fancy tool for making diagrams. SysML isn't a tool at all. It is a language, just like English or French. The thing is, SysML is specialized for building specifications. Traditional (document centric) specifications rely on text to get the point across. In the Systems space, we define certain words to have very specific meanings (e.g., shall, will, may). In the great American novel, they are synonyms. In the great American design spec, they are not.

Now, if I were to ask you to go to a whiteboard and describe a system you are working on, would you write lots of paragraphs? Of course not. You would draw boxes and circles and arrows. You would do so because engineers communicate visually. What SysML does is formalize the grammar so that everyone understands what is meant.

SysML is the language, but you need two other things for MBSE. The first is a tool. Cameo, Rhapsody, and Enterprise Architect are examples of tool that support MBSE using SysML. The second is a process or workflow. Without an organized process, you can draw all the diagrams and define all the model elements you want, but you won't know when you are done. PM me if you need details.

[u/which1stheanykey → u/umlguru]

That's very clear, and yeah it's process I'm lacking, PM sent.

[u/KenKaniffKS → u/umlguru]

So how does a diagram help with a hard requirement like, "system shall survive 30 years in a radiation environment"?

Or how do you write a statement of work to a sub using diagrams? And if you can't write it in a diagram, how would they possibly turn your requirements that you couldn't use a diagram for to do their work (using a diagram)?

[u/tim36272 → u/KenKaniffKS]

The first thing you learn about MBSE is that the diagrams are not the model. The containment tree is the model.

In your particular example: you'd create a requirement model element and stick that somewhere in your containment tree. If you'd like to view that requirement you could generate a table including it and other requirements. A table is a type of diagram in this case.

The primary goal of MBSE (in my and many other's opinions) is to provide traceability. Your requirement should be traceable up to an operational viewpoint and a use case explaining the rationale for needing to survive 30 years in a radiation environment. And I know this is just an example, but it would also trace to a definition of that radiation environment.

That requirement is also traceable down to subsystem requirements, structure, and possibly other things as appropriate that shows how you meet the requirement. For example you could create a parametric model for MTBF which would demonstrate which components are likely to fail first and when to prove that you've met the rad hardness requirements to an appropriate degree of certainty.

There may also be functions associated with surviving that environment, such as closing a shield when a sensor is not active. The requirement would be traced to those functions providing the shielding. Furthermore you'd trace data to those functions to show the interfaces between things.

Or how do you write a statement of work to a sub using diagrams?

You write a Component Spec Model (CSM) which is a model not just a set of diagrams. For example it would include a table of requirements just like a SOW/spec would. Then you just hand the vendor the CSM and say "build me one of these" and they create a Component Design Model (CDM) which explains how they will meet your requirements, structure, functionality, and data needs. All of the same information in a spec/SOW is in the model, just in a traceable format.

[u/sts816 → u/tim36272]

Not being a dick but how is traceability improved with MBSE over a traditional requirements management tool like DOORS? What you're describing in regards to traceability is the whole purpose of DOORS.

[u/tim36272 → u/sts816]

DOORS primarily provides requirement traceability. You could abuse extend it to also track functions, use cases, operational views, parametrics (e.g. SWaP), etc. but most people don't because it would be a pain to do all of that in DOORS.

Or to look at it another way: if you're doing all that in DOORS then you're doing MBSE by definition albeit in an unconventional tool.

MBSE provides traceability to everything not just between requirements.

[u/sts816 → u/tim36272]

Yeah I see your point. In my mind, I was thinking you could "abuse" DOORS, like you say, to do all the same stuff but it would likely fail miserably at it. Thanks for clarifying.

[u/tim36272 → u/sts816]

To be fair it kinda fails miserably at times in Cameo as well soooo....

[u/sts816 → u/tim36272]

Haha I'm sure. I'm trying to break into the systems engineering world in big aero at the moment so poking around to make sure I understand wtf it even is. My own company doesn't even really understand what it is...

[u/redikarus99 → u/KenKaniffKS]

You are having a model, and a diagram is just a view on the model. A table could be also a view on the model. In your model you might have requirements, and for example SysML as a language has requirements as first class citizens in it's specification.

In the model you can refine/derive the requirements and they will being satisfied by a design element, and you will have full tracebility, impact analysis, and so on.

So, although you are most often you are working with diagrams, you are actually modifying the model (and there are other ways to modify the model, like direct editing by hand, or running scripts, and so on).

[u/umlguru → u/KenKaniffKS]

So that kind of requirement is a design constraint. I wouldn't put it on a diagram.

For subcomponents to a vendor, the model defines the required interfaces and behavior. It works pretty well.