5 MBSE Myths You'll Be Happy to Learn are FALSE!

5 MBSE Myths You'll Be Happy to Learn are FALSE!

Despite what some old hats may prefer, Model Based Systems Engineering is here to stay. It’s a new, better way of doing systems engineering. With every new thing comes much chatter. Some of it may be true, and some of it you’ll be happy to learn is completely false. So what are the current myths about MBSE?

Myth 1) MBSE is only beneficial for large projects.?In reality, implementing MBSE on smaller projects will prove to add value over a document based approach. A system model helps stakeholders understand the intent of a system and its purpose within a specific domain. From customer requirements to engineers of all kinds needing clear direction on what they are tasked to develop, having a system model expressed in a common language such as SysML can make the difference in a product eventually realizing success or failure. Beyond this, when changes occur, a model is much easier to update than documents that require systems engineers to make manual changes to tables, glossaries and requirements etc.

Myth 2)?The best MBSE tools such as Cameo Systems Modeler are too expensive.?If you’re currently in the exploratory phase of evaluating MBSE tools you’ll notice the sticker shock of choosing Dassault Systemès’ Cameo Systems Modeler versus a tool such as Sparx’s Enterprise Architect and be tempted to choose the cheaper, Sparx EA option. Cameo Systems Modeler is a more capable, user friendly tool, however. The problem when evaluating the options is that it is difficult to compare apples to apples due to the pricing strategies of the tool vendors. Sparx EA, for example, has an attractive low(er) monthly payment plan that seems to be much less than Dassault’s Cameo Systems Modeler which hits you with an up front cost, accompanied by a yearly “maintenance fee.” The big difference, though, is that Dassault’s licenses are typically perpetual, meaning you’ll pay for them in a larger up front lump sum, then you?own?the license and that cost does not repeat monthly or yearly. You are only obligated to pay the yearly maintenance fee which ends up being less than Sparx’s EA over time. With that in mind, Dassault has recently began offering a license “rental” option for customers who prefer to avoid the larger up front investment and opt to pay monthly. The downside to this option is, of course, that you do not own the license perpetually and will be obligated to pay the monthly fee, as well as the yearly maintenance fee. Still, this can be a more attractive option for customers who may not be ready to fully commit to the larger initial investment.

Myth 3)?Requirements should be managed in separate repositories than the “SysML model.”?There is still a cultural shift happening where many projects have “requirements” stored in databases such as Jama, DOORS, or yes, even Microsoft Word and Excel. Times, they are a changin’, however, and this is all for the better. Close your eyes for a moment and imagine the perfect scenario where you, as a systems engineer, have all of the data you need in one place, such as Cameo Systems Modeler. This is the best case scenario because it is most efficient and easiest to manage. Having requirements stored in a separate repository than your SysML model requires digital threads or plugins to synchronize the traceability of the requirements to their architectural realizations. This comes with a cost of course, time and possible broken synchronization which all add up to higher program costs and potential failures. The truly best scenario is to have requirements as close to your authoritative source of truth as possible which should be the SysML model. Cameo Systems Modeler, for example, is very capable of managing requirements and offers easy ways to customize and extend the out of the box properties associated with requirements to meet the program’s needs. The greatest benefit in having requirements directly in the SysML model is that it is much easier to create traceability between the requirements and the system architecture, as well as quickly react to changes, when they occur.

Myth 4)?Simulating a SysML model is pointless.?You’ll be happy to know that it can be extremely valuable to perform simulations in a SysML model. Starting with the most obvious value add is the ability to demonstrate the systems’ intended functionality to stakeholders in an effort to determine if the planned implementation meets the requirements. Having the ability to show a customer how they can interact with their system before the software engineers develop a never-intended architecture is invaluable to stakeholders. Another value add for simulating SysML models is the semantic checking for language consistency that may be missed by systems engineers if simulations are not performed. When a simulation is performed, it provides immediate feedback to the engineer if they made a mistake in their work. One example of this is a mistake made often where practitioners will model a loop in an Activity by having a control flow begin at an action and having it return to the same action rather than to a merge node preceding the action. This may look proper to the untrained eye, but it violates SysML due to the idea that an action will only become enabled when all “incoming edges” have a token. That means that the control flow “edge” that shows the loop will never provide a token and therefore inhibit the action from ever becoming enabled. This issue will be realized immediately by engineers when they attempt to simulate their Activity and find out quickly that what they modeled does not work.

Another example that is commonly seen is when engineers use a Time Event in an Activity diagram. The Time Event defaults to an absolute time with an “at” notation preceding the specified delay rather than what most engineers typically intend to model which is a Time Event with a relative delay, notated by “after” such as “after(1s)” meaning after 1 second. To change a Time Event to a relative delay, a Cameo user must change the default “Is Relative” property to true from its “false” default setting. This is an issue that is usually not detectable, even using a Validation Suite due to it being technically “correct” but likely not desired. By performing a simulation of this behavior, the engineer will immediately realize they need to make a change prior to committing their work to the latest version of the model.

Beyond these simple examples, much more complex simulations can be performed using parametrics which can be coupled with the behavior model to predict if requirements will be met within the constraints of the system. To perform such simulations in Cameo Systems Modeler, you’ll need the Cameo Simulation Toolkit plugin. This can be purchased as a separate add-on or included in a bundled license package such as Cameo Enterprise Architecture.

Myth 5) The learning curve for learning a new tool and a new language is too steep.?Can’t teach an old dog new tricks? False! We can all spare a few brain cells for some new tricks and that’s really what keeps our lives the most interesting and from keeling over in boredom. Do you really want to be a systems engineer who uses Microsoft Word forever and has to manually update your Requirements Verification Trace Matrix (RVTM) by hand, and has to deal with indentations and image captions until you feel like pulling your hair out? I didn’t think so! Time to learn a few new things. Trust me, as someone who started as a document centric systems engineer in 2016 and said to myself “surely there has to be a better way,” I assure you, the grass is greener on the MBSE side, and you are very capable of learning a new, better way of doing systems engineering.

If your organization is in need of assistance transitioning to MBSE, Strategic Technology Consulting (STC) is here to help. We have a team of 100+ Model Based Systems Engineering experts who are ready to assist your efforts in teaching, modeling, and building your MBSE infrastructure. Contact us as?www.sTechnologyConsulting.com

Need licenses for Cameo Systems Modeler, Cameo Simulation Toolkit, or other Dassault Systemès products? STC is a Dassault Systemès partner and an authorized reseller of licenses. Contact us at?www.sTechnologyConsulting.com?for a quote today.

Going a bit further (now that it's not 2:30 AM) on Myth 3: Certainly, we prefer to settle on the Digital Engineering (DE) & Integration processes before we use any tools. We also realize that for any integration that may involve a myriad of (evolving) data interchange demands over time, we still need to understand the value that tools can introduced into the process - as we see it today & as it may become tomorrow. By adding tools, are we simply inserting more independent data to be included in the DE process, or do the new tools enable the creation of new interdependent data resulting of the digital integration? In the absence of adding tools, the other alternative is to invest in (sometimes unknown) software development & data integration services. Future budgets and funding for particular SME services (internal or external), may not a certainty, either. Many organizations already use a variety of MBSE tools. But if their development contracts don't include any direct ties to, say, maintaining a deployed system (or subsystem) - it may make sense to stake their digital engineering boundaries around the design development process. Software development teams may suit this objective just fine. 1 of 4

Agree with much of your message & what those who commented had to offer. I’ll address your philosophical approach to “Myth 3” since this is more of a matter of imagining MBSE as either involved in a “Conjoined vs. Interdependent” approach to full-integrated systems design in a Digital Engineering process. Approaches to MBSE that aren’t able to leverage the digital integration via a digital means to become capable of synthesizing interdependent design activities (Reliability, Risk & Sarety, Test, Level of Repair, Operational Health Management & Agile Maintenance Strategies, etc.) will have a lower ceiling in cost/benefit analyses to those approaches that can offer a robust segue to these interdependent approaches to MBSE. A “Conjoined” approach will be limited by the growth potential of the SSOT itself, unless the API within the SSOT is intended to mature the synchronizing of ontologies & syntax variations for each design & support discipline. In some cases, the reliance on an API becomes a limitation to the growth potential of the MBSE process that will lead to resorting to merely using the SSOT to function as a “Conjoined” approach to the digital engineering. There will be a course on this at Autotestcon In August 2023.

Mike R.

Chief Engineer

2 年

Nice list, could we add myth 6? MBSE is only about building models using SysML in a tool like Cameo. MBSE is the use of models to support any SE process. Linking your architecture model to a simulation to validate metrics and requirements against design? Now that is MBSE.

Markus Nordstrand

Systems Engineer at Kongsberg Automotive

2 年

Regarding 3, the problem with this approach is that the only person that can update the requirements is the "Modeling expert". Also regarding 3, there are as you say DE tools that do this. The Rhapsody-Doors Next integration via the ELM platform as actually quite seamless regarding this. You only select the correct global configuration in rhapsody and - boom - you are always in sync. You can edit your requirement in Doors Next on one screen and update and link to the SysML model on Rhapsody on the other screen and it's always in sync.

要查看或添加评论,请登录

Brian Moberley的更多文章

社区洞察

其他会员也浏览了