How has SysMIL (specifically) helped your project?

[JP]

I recently got hired at a company where the customer was requesting SysML diagrams. Mind you, I'm entry level (finished grad school a year ago and worked as an adjunct instructor in the time in between), and I got hired because UML was my favorite course in grad school (I'm a math major, by the way) and making UML diagrams is something I'm enthusiastic about. I didn't know what SysML was until my current employer contacted me, and since then I've bought the four (are there more?) books on SysML and now I'm as comfortable with SysML as I am with UML.

 

However, at the moment I'm not tasked with making diagrams, I'm tasked with explaining to my group why SysML/MBSE is a good thing. And while I can recite the good reasons for it from all of my books (makings models makes you think, having a model allows you to make changes and trace their effect on the model, use cases are a good start for test cases, better communication with the customer, etc.), they feel the examples/reasons outlined in the books are insufficient and are looking for more concrete examples of how SysML is helpful.  My only issue there is, I'm entry level so I have no real world experience with using this stuff on a project, I just understand academically why it's a good idea. My gut feeling is that why MBSE is useful will become more apparent as we use it, but we're still waiting to get rolling at the moment, and this is what they want me to do in the meantime.

 

So, does anyone have any specific ways that SysML helped their project (that they can and are willing to share)? Even if you change the names of blocks (i.e. I had a block named widget that was composed of several instances of doodads... ) it would be helpful. I'm just looking for concrete examples of how SysML (or a SysML tool) solved some actual problem.

[Jong Chen]

We have just started using SysML at where I work.  We develop high security products that require certification.  SysML has helped us in two ways.  To achieve certification we need to describe how our system implements the security requirements imposed on us.  In the past we would take each requirement and write a whole bunch of text to explain how our system implements that requirement.  As you can imagine that was very cumbersome and difficult for our security evaluators to understand.  We switched to a combination of SysML diagrams and text to describe our system.  We have not entered our certification phase yet (so I don't know how the evaluators will like our documents) but I can already see that it is easier for our internal Software / Hardware / Firmware engineers to understand the system.  The biggest thing is that they can see how each of the component they are responsible for is interacting with the rest of the system.  When the engineers are making design decisions it is easier for them to visualize the impact that it has on the rest of the system.

We are also creating a black box model of our system.  Our system is quite complex with 8 separate connections to fully independent systems.  There are times where the 8 systems needs to coordinate their actions (outside of our system) in order to properly configure us and transfer data through us.  The interactions between the 8 systems and our product can get quite complex.  The black box model allowed us to work through some very complex behavior that resulted in hardware, firmware (FPGA) and software design changes.  Had we not created the model we would have discovered all of those issues during system integration where we would have to either take the schedule hit to re-spin the board or to "live with" the issues.  

The black box model also is going to really help with the creation of our users manual.  We are planning on taking diagrams directly from the model and putting it in our users manual.  A few pictures goes a really long way in explaining how our system operates.

A hidden side benefit of SysML for me is that I get to focus on describing my design.  In the past we used block diagrams and flow charts with no real guidelines and I found that I spent more time trying to figure out how I wanted my pictures to look than the actual content of the diagrams.  

If I were you I would not try to do a big push and mandate that SysML be adopted company wide immediately.  Until you have developed a good process to utilize SysML (how do you create a model of the system? Which methodology are you going to use?) there are going to be some confusion.  If there is a high profile failure of a project / task all of the blame will be placed on SysML and then no one will ever probably use it again in that company.

I'd recommend starting small.  When generating documentation, start using SysML diagrams.  When discussing issues with engineers start using SysML diagrams.  When designing a system do a model of a small portion of the system.  As people start seeing the utility of SysML hopefully they will start to use it.

Don't do what we did.  Our first model was extremely complex.  It has been years and we are still working on it.  Because it was our first model there were tons of issues with it.  Now we are too far along with the model to fix the issues with the model.  During the creation of the first model we have created lots of secondary models to describe limited portions of the system.  Each of those models took maybe 2 weeks to complete.  As we completed each of those models we were able to refine our model creation process and each subsequent model was faster / easier to complete.  Now we are stuck with how we created the first model and can't apply the lessons learned to it.  This is painful.

[geoff]

JP,

 

I'd like to suggest you look at the information here: http://mbse.gfse.de/index.html

 

Specifically the Telescope section.

 

No Magic makes a "READER" version of Magic Draw as well as Cameo available at no cost so you can download the MBSE plugin and the model and really illustrate to others what a model is and how a model in a good tool adds value, as compared to simply "diagrams" (e.g., visio or similar).  Block diagrams have been a mainstay of SE for a long time along with functional flow block diagrams and N2 diagrams, etc...  (It's a long list).

 

MBSE doesn't change the fundamentals of the SE practice processes, it merely alters the methods and tools of the practice.  MBSE delivers an enormous value to the practice and the value proposition is too extensive to elaborate in this forum.  I you haven't read any of Rémy Fannader's work @ http://caminao.wordpress.com/ I'd like to suggest you do.  Rémy is very insightful!  Also read the Cookbook (both volumes) from mbse.gfse.de

 

If that doesn't completely satisfy try Tim Weilkiens sites.  sysmod.de (systems modeling practice) & example.system-modeling.com (example model using sysml and Tim's SYSMOD)

 

 

[Gjalt de Jong]

I do not know what your application domain is. You might have a look at the following paper where SysML has been used for an automotive braking system and safety analysis.

http://papers.sae.org/2014-01-0212/

 

Kind regards,

Gjalt de Jong

--

Gjalt de Jong

ArchWorks

Antwerpsestraat 2/C3

B3290 Diest

Belgium

tel. +32 13 784089

GSM +32 473969545

mailto:gj...@acm.org

--
--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to
sysmlforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sysmlforum+...@googlegroups.com.
To post to this group, send email to sysml...@googlegroups.com.
Visit this group at http://groups.google.com/group/sysmlforum.
To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/9c6d6ad5-5234-4b22-8aff-9c094b339665%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthew Hause]

Tom Gilb has a golden rule for projects: If you don’t know what you are doing, don’t do it in a big way. Start small and work from there. And your priority should be People, Process, Tools in that order. Finally, get a consultant or two with a proven track record to help as well as some training. There are many ways to adopt MBSE wrong, and you want to figure out what is best for your company.

--

--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to
sysmlforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sysmlforum+...@googlegroups.com.
To post to this group, send email to sysml...@googlegroups.com.
Visit this group at http://groups.google.com/group/sysmlforum.

To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/ea72fdce-9f08-442b-8fc1-f4da041076e6%40googlegroups.com.

[geoff]

JP,

 

You've received some good feedback here. 

 

If you don't know who Matthew Hause (LinkedIn Profile) is then perhaps you may not appreciate fully his advice.  Mr. Hause is a key player and highly influential in the MBSE domain.  His advice to have an experienced consultant guide your effort is of paramount importance.  Success without such guidance is unlikely. 

 

You need quality training in the language, processes and the tools.  As others have stated, there are plenty of ways to do things wrong and only a very few ways to do them right.  Transitioning to an MBSE methodology represents a substantial investment by your company, but done properly there will be a payback.  Done wrong, the probable result without experienced guidance, you will more than likely fail and tarnish the methodology forever in your organization.

 

When I recently presented on the topic of MBSE to my local INCOSE chapter one of the questions I received was "What would be your first recommendation to an organization transitioning to MBSE?".  I quickly responded "Get a mentor to guide your efforts".   

[JP]

Everybody,

 

 Thanks for all of the advice! It has (and I imagine will continue) proven to be incredibly helpful.

 

(I had originally replied to every single post here thinking the replies would be nested, but I deleted them when I saw all four posts back-to-back at the bottom, sorry for any confusion!)

 

I also appreciate the comments on finding a consultant, however, my employer is a contractor, and our customer is the one switching to MBSE, so we're really following their lead (as my employer isn't switching to MBSE overall right now). Whether or not our customer brought in a consultant, I'm not sure, but judging from the information I've seen and the fact that they seem to be going with a modified OOSEM methodology,  I assume they have. My role is: "Hey, your resume' mentions that you like UML, come over here and help us figure out what these SysML guys are talking about, and eventually make SysML diagrams for this project." And given the incredible amount of feedback and insight I've gotten from you guys, I'm certainly off to a good start in helping my bosses understand why our customer has decided to go with MBSE via SysML. So again, thanks for all of your help!

[JP]

Oh, and from what I understand there is talk of bringing some type of consultant in once we get settled in with our tool (Sparx EA). I'm a bit foggy on those details though and I don't think anything was set in stone. (Just to clarify in case my last post seemed to "brush off" the idea of a consultant; that is not what I intended, I was just noting that my employer isn't going full in with MBSE, and that that's mostly the customer).

[geoff]

OOSEM:

 

What does your organization know about OOSEM?  Do you have documented technical processes and methods for OOSEM?  Do you use Rational Methods Composer or Eclipse Process Framework Composer to deliver your SE processes to the development team?  There was a rumor of work on a version of an OOSEM EPF wiki (J.D Baker is associated with this information), but I've never seen evidence of it.  Have you (and the execution team) read the OOSEM tutorial from JHU?  In what way has your customer "modified" OOSEM and why?  What benefits are derived from the modification?

 

What is your enterprise's current SE methodology?  How does your current SE methodology differ from OOSEM?  What understanding of different MBSE methodologies does your organization command?  Methods, artifacts, etc...  Have you and the execution team read IBM's Rational Harmony Deskbook?  There is also good Model-Driven Development content here.

 

First the team must learn the language, next the processes and methods of the processes and lastly the tool.  Many tools are NOT methodology agnostic.

 

I'm guessing the selection of Sparx EA was largely driven by price.  Does this tool provide the capabilities required by your customer's MBSE methodology (OOSEM modified)?

 

"my employer is a contractor": Who is doing the SE, Your company or the customer?  If the answer is 'your company', your company needs in-depth knowledge of MBSE to successfully (and this isn't a guarantee) perform on the contract.

 

Do you have a Chief Systems Engineer knowledgeable  in MBSE methodologies?  Your chief SE should be leading this charge.

[geoff]

I've been doing more research today into the availability of comprehensive OOSEM documentation.  If it is in the public domain, I can't seem to find it.  Again, JD Baker and APG are mentioned frequently in connection with OOSEM PROCESS documentation.  Truly unfortunate this effort never saw the light of day in the public domain.

 

JP - I'd also like to suggest to provide your technical leadership with this presentation that Matthew Hause presented last year "How to Fail at MBSE".  This is 'spot on' advice from a leading professional in the domain.  Read and Heed!  Mr Hause is providing his sage advice for free.

 

 

[Matthew Hause]

The problem is that you are limiting your success by not investing in some competent consulting. I have been using UML/SysML o 20 years and developing systems for 20 years before that. When trying to adopt new techniques and tools, you need to understand what you want to accomplish before you start, then define a process for how you are going to get there, and finally find the right tool to help you achieve your goals. I am afraid you will not obtain much more that you could with power point or Visio and that your models will be of little use. I have seen this more times that I can remember. I do wish you luck in your task though. Let me know if you need help.

 

Also, I will be teaching a half day course on MBSE and SysML at the INCOSE symposium in Las Vegas in July. Come along if you would like an introduction.

 

From: sysml...@googlegroups.com [mailto:sysml...@googlegroups.com] On Behalf Of JP
Sent: Monday, June 16, 2014 11:43 AM
To: sysml...@googlegroups.com
Subject: [SysML Forum] Re: How has SysMIL (specifically) helped your project?

 

Everybody,

--

--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to
sysmlforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sysmlforum+...@googlegroups.com.
To post to this group, send email to sysml...@googlegroups.com.
Visit this group at http://groups.google.com/group/sysmlforum.

To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/2156d99a-1c82-407e-9fdd-48b78dba4bd4%40googlegroups.com.

[Philip Oakley]

Hi,

I'm starting to look at methods (and tools) of capturing the fuzzy
system context and global level 'requirements' for some future systems
we are developing.

The problem comes in that those specifying the future system are just as
much in the dark as ourselves as to the whole future operating
conditions. There are some major changes that will fundamentally change
the operating environment, and hence most of the natural assumptions
folk make could well be wrong, leading to wrong specs and wrong designs.

It's as if we are designing (and by implication specifying) the modern
car, yet we currently use horse drawn carriages, so the task is, as
Henry Ford said (allegedly) "the customer wants faster horses". We
already know that we need rid of the horses, and possible the driver
(we'll have to drive ourselves, shock horror!).

The question is what are the methods and support tools that folks can
suggest to capture this wooly real world domain information (I avoid
calling it knowledge because of those customer confusions;-) that really
work?

We don't want to (won't) use the classical 'requirements management /
traceability' tools because of their inappropriate focus
(inward/downward), rather than the view we need to understand of outward
& upward (e.g. P Checkland's Stage 1 [The problem situation
unstructured] and then onto stage 2 [the problem situation structured]).

In this case we would then [hope to] map out the potentail technical
design options to improve the situation, perhaps even leading to
reaching a Model T design ;-)

So, have folk any suggestions for capturing the unstructured 'mess' with
methods and tools in SysML/UML or other formats?

Philip Oakley
Systems Engineer

[Remy Fannader]

Hi Philip,
For that purpose you need a shift in the modeling paradigm introducing two critical distinctions:

1. Between objects and activities in context (including systems) on one hand, their symbolic representation on the other hand.

2. Between intensional and extensional descriptions.

UML stereotypes on that basis will then do the job.

Here two starting points, I will be happy to give you more.

http://caminao.wordpress.com/what-is-to-be-represented/
http://caminao.wordpress.com/about/reflections-for-the-perplexed/

Rémy.

--
--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to

sysmlforum+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
--- You received this message because you are subscribed to the Google Groups "SysML Forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sysmlforum+unsubscribe@googlegroups.com.

To post to this group, send email to sysml...@googlegroups.com.
Visit this group at http://groups.google.com/group/sysmlforum.

To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/AC442ED9A3D84616BBB82DA5C555C183%40PhilipOakley.

[Martin, Bryce E]

Philip,
I am jealous that you have the privilege of working on a project that is a clean sheet design! :)

Ok, now that that is out of the way, here is how I would address the problem at hand.

I would use SysML only and I would be sure to use an object oriented tool (not Visio, PowerPoint, etc). The real power behind SysML/UML is the ability to create a relational database that connects all of the details of each element in the system design, not just pretty drawings. So, when one thing changes in the environment or system you can easily identify the impacts and make the necessary changes relatively quickly.

Now to the approach. I would start by modeling the external environment, or what I like to call the Enterprise. This includes all of the elements that are external to your system that it must interact with either directly or indirectly. And it typically is not necessary to capture every detail about the Enterprise, but just what is important to the operation of the system of interest (aka, what you are designing). And, since you are already realizing that this external environment will change, plan to review this part of your SysML model on a consistent basis and update it as needed.

Once you have a good handle on the current state of the external environment then you can start to model your system. I would highly suggest that you keep you system model at a pretty high level until you settle on a firm set of customer needs/objectives/requirements. I would model the system as a single block that is a part of the Enterprise model that I just created. I would then utilize Use Cases to capture what I think are the operational objectives of the systems, including what the actors are. This is where I start to identify how the system interacts with the external world. I am not identifying how the system interacts, but just who it interacts with and identifying that it must do something. Then I would start to decompose these use cases a bit utilizing sequence diagrams and activity diagrams. Also, I would start to capture what I think the states and modes of the system are with State Machine diagrams. This behavior modeling with Use Cases, Sequence Diagrams, Activity Diagrams and State Machine Diagrams does not have to be overly complex, especially if you are trying to determine how your system must interact with a dynamic environment. Think of your system as a black box at this point. You really don't care how the system does what it needs to do, you just need to figure out what it needs to do to accomplish the mission.

Finally, notice that I have not really mentioned requirements at this point. Based on what you have said you do not want to artificially constrain yourself by specifying requirements too early in your design process. Let the design process determine what the requirements are. It really is the customer/stakeholder requirements that should constrain the design and until you have those you are just guessing at what those are, so treat them as objectives, in other words, something to shoot for, but not necessarily hard constraints on your deisgn.

I hope this helps.

Bryce Martin

--
--
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com To post to this group, send email to sysml...@googlegroups.com To unsubscribe from this group, send email to

sysmlforum+...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sysmlforum+...@googlegroups.com.

[Philip Oakley]

Thanks for those refs, Remy, I think I've seen one  of them before but had forgotten ;-)

 

The 'reflections' article does give 37 different distinctions, so we have more choices (2^37) than people in the world (~2^31) - and I can see that within our system design! No one can agree on what will be required - there are some that still want hover cars for their horseless carriages.

 

The other part of my original question was what support tools folks have found helpfull during this difficult stage when clarity is in sparse supply.

 

Philip

[Philip Oakley]

Hi Bryce,

No need to be jealous, the sheet isn't that clean - it's making sense of
all the doodles and Rorschach ink blots that's a big part of the problem
;-)

Some of the problems are the issues Remy mentioned in his linked article
http://caminao.wordpress.com/what-is-to-be-represented/ it's the
problems for we systems engineers when the 'entwined contexts' include
"laws of physics" limits which then conflict with the 'must have'
desires.

During this fluid stage one issue will be keeping track of the on-going
conflicts, misunderstandings and other politics, which doesn't appear to
be something that's normally covered in the Sys Eng processes. [one
reflection is to look at Quinn's Competing Values Framework (CVF) and
note how one quadrant is always ignored in any organisation - the one
diagonally opposite the organisations core competence, for example
limited HR (human resources (sic)) in engineering companies]

Capturing and linking this soft information is still a tricky step.

Philip

----- Original Message -----
From: "Martin, Bryce E" <bryce.e...@lmco.com>
To: <sysml...@googlegroups.com>

https://groups.google.com/d/msgid/sysmlforum/43F4BDEBBD70C749866D97A3649309696C73D74C%40HVXDSP41.us.lmco.com.

[Remy Fannader]

Philip,

Here a very effective routine to eliminate ineffective or irrelevant definitions:

1. Effectiveness: applying candidate definition to targeted instances must provide clear and unambiguous answers (or mutually exclusive subsets).
2. Usefulness: the resulting answers (or subsets) must directly support well-defined purposes.

Such routine meets Occam’s razor parsimony principle by producing outcomes that are consistent (“internal” truth, i.e no ambiguity), sufficient (they meet their purpose), and simple (mutually exclusive classifications are simpler than overlapping ones).

The outcome can then be refined through semantic analysis.

http://caminao.wordpress.com/2014/06/05/fiddling-definitions/