RE: [SysML Forum] SysML Models and Production
Eran Peleg (Netvision)
Hi
The main question of the dual-port issue is the support of dual-port on the same item in production vs. production of the part either with one port - CAN or Ethernet. If the second option is true, one should pay attention to the upcoming CVL standard from PMG (http://www.omgwiki.org/variability/doku.php), dealing with the concept of Product-Line. Basically, the CVL concept is transformation (Materialization) of a base model to the product model according to the variability model (specified using the CVL) and the transformation engine.
A good concept for product-line implementation.
Have fun with modeling
Eran
=============================
Eran Peleg, CEO, Metaphor Vision Ltd.
Phone: +972545346060
eMail: epe...@metaphor.co.il
Skype: EranPelegMetaphor
=============================
From: sysml...@googlegroups.com [mailto:sysml...@googlegroups.com] On Behalf Of Dan George
Sent: Saturday, February 23, 2013 6:58 PM
To: sysml...@googlegroups.com
Subject: [SysML Forum] SysML Models and Production
Hi,
The discussion about "How design two interfaces in the same SysML model ?" demonstrates and example of a problem I've been wondering about. The issue in that discussion was how to use a generalized part type w/o having to specialize the part for the type variation of components. In this case an Equipment block had a communication port and the variations were CAN and Ethernet.
A traditional approach is to assign a major part number for the generalization and tabulate the variations. For example, 12345-00 would designate Equipment with the CAN port and 12345-01 would designate Equipment with the Ethernet port. It is obviously important for production to know exactly which BOM, assy dwg, process docs, etc. to use for each work order. The numbering scheme enabled unambiguous linkage of part to documentation and worked its way all the way to the start of the design process. As soon as Engineering recognized the need for Equipment, they would obtain the base part number, in this case 12345-00. As the design progressed, documents would be created for 12345-xx and tables would be added to the documents to handle the variations. In this case, 00 for CAN and 01 for Ethernet. The identification was critical to enable effective production of the end-items.
I never see part numbers in SysML diagrams. In the books, it is practical to elide that detail for the same of clarity on the language itself. However, I never even see a nod to this issue. Is there some other scheme in place that eliminates the need for part numbering in engineering documentation? Is there a model transformation tool that generates production documentation and applies part numbers at that time? Is SysML limited only to simulation?
I hope this topic is okay for the forum. It isn't about the language so much as about practical application of SysML models beyond simulation. I hope others are interested in how models fit into the overall product lifecycle.
Thanks,
Dan
--
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
FAUDOU Raphael
Hello Dieter,
You still have the choice to implement CVL language as a separate language or as a UML profile. It is just a matter of tooling support and user experience. What is important to consider, from my point of view, is that variability is orthogonal to development phases. Variability has impacts on requirements/specification, design, validation, documentation... so it is not just a matter of adding a few elements on blocks in SysML and use inheritance: that ‘s just not enough.
By using a profile implementation you can then add variability on use cases, interactions, activities, states, blocks, properties.... and manage variability as a dedicated viewpoint on your sysML model.
Note: I had the opportunity to create such a profile last year in the context of a UML/SysML training for Eurocopter and it worked.
Hope it helps
Regards
Raphaël
Raphaël Faudou
Head of R&D, methods and tools
Embedded & Critical Systems
T +33 5 34 363 289
De : sysml...@googlegroups.com [mailto:sysml...@googlegroups.com]
De la part de Dieter Van Eessen
Envoyé : mercredi 27 février 2013 18:46
À : sysml...@googlegroups.com
Cc : epe...@metaphor.co.il
Objet : Re: [SysML Forum] SysML Models and Production
Hello Eran,
About CVL: why does it try to separate variability models (in the realization layer) from the base model (abstraction layer) with a complete new language. Why must it create an entire new language instead of extending UML/SysML with a variations-profile (as
the one in SYSMOD-profile or an extended version) which would keep all variations within the same model. Depending on the type of variation, I consider their presence in the current model as required:
- a new model is often an extension/change to an old model. VARIATIONS IN TIME (version management) should be part of the model as they often are the reason new requirements are have been. A great way to go forward is by looking back.
- choosing working principles is considered an important part within system engineering. VARIATION IN SOLUTION (similar to ObjectExistence/Choice within CVL). Keeping this inside the model will inform viewers/team members that certain pathways have been considered,
but not found useful.
- if a variation in solution happens on higher level, the base model may change alot depending on choice. How to deal with this? If variations are kept within the model, high level decisions can also be modeled and explained.
- for parameter variation I don't see why to choose CVL over SysML (SysML also provides the possibility to create several 'realizations')
Thus the main question: why does OMG try to pull out variation specification from SysML?
Kind regards,
Dieter
On Saturday, February 23, 2013 9:12:12 PM UTC+1, Eran Peleg wrote:
Hi
The main question of the dual-port issue is the support of dual-port on the same item in production vs. production of the part either with one port - CAN or Ethernet. If the second option is true, one should pay attention to the upcoming CVL standard from PMG (http://www.omgwiki.org/variability/doku.php), dealing with the concept of Product-Line. Basically, the CVL concept is transformation (Materialization) of a base model to the product model according to the variability model (specified using the CVL) and the transformation engine.
A good concept for product-line implementation.
Have fun with modeling
Eran
=============================
Eran Peleg, CEO, Metaphor Vision Ltd.
Phone: +972545346060
eMail: epe...@metaphor.co.il
Skype: EranPelegMetaphor
=============================
--
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par
erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient
faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet,
the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting
from any virus transmitted.