| Re: [esf-dev] ESF More Tightly Anchored to SysML |
-------- Original Message --------Subject: Re: [esf-dev] ESF More Tightly Anchored to SysMLLocal Time: February 8, 2016 3:42 amUTC Time: February 8, 2016 8:42 AMHi Dan,
First, thanks for your interest in our project, all ideas and comments are welcomed !
I think that you have correctly understood our goal when we have started the project : try to formalize and spread the MBSA (Model Based Safety Analysis), to ease the interactions between design and safety assessment activities. Building an Open Source tool is also an important choice to achieve this. That's why we want to build a fully customisable tool, which can help the safety engineers to perform its "standard" analysis, but which can also be modified and enriched to be suitable to any specific needs.
The first step was to build a metamodel opened to the different approaches (FTA, FMEA, etc.) and domains (ISO 26262, etc.). The metamodel architecture is thus organised in different layers, from a common core to the specific layers. We also had to choose on which standard metamodel we can rely : UML or SysML. It's true that we have some concept tightly related with SysML ones for the architecture part (like SBlock, and SPort). But we thought that it was not efficient to depend on all SysML just for these concepts. This leads us to define our own architecture part but to be clear for any user that our 'Block' is not the 'SysML Block', we have decided to use a prefix for our own concepts (SBlock, SConnector, etc.). This choice can be discussed, as we had some opposing opinion from users.
By the way, we have organised some open discussion between CEA, ALL4TEC and other industrials about the metamodel as it will continue to evolve. Do you want to be invited for the next sessions ? It can be a first step to contribute to the project.
Regards,
Jonathan
Le 07/02/2016 03:49, dyeaw a écrit :Hi everyone,
I'm new to the mailing list, so a quick introduction is that my name is Dan and I help lead functional safety analysis for one of the large automotive OEMs. Like others in the automotive industry, we have already developed our own custom profiles in order to conduct functional safety analysis using MBSE. I am passionate about helping to spread and accelerate the use of MBSE across all industries, and I think the best way to do that is to break down the closed off processes, methods, and tools to open source alternatives that everyone can freely build off of and improve.
I was excited to see the ESF project, since it has similar goals to provide open source safety modeling. I did notice that the current plan in the ESF Metamodel Profile conventions is to create prefix all model elements with a S.
For safety (or security) to be effective, I believe that it has to be tightly integrated with other systems engineering activities in an organization that are also being conducted to achieve a quality product. So this means that ideally all of systems engineering activities use a common model of the system so that the design of the system for safety and security is consistent with the base functionality and failure mode avoidance. Although not perfect, SysML already provides a modeling language that provides the ability to create a descriptive model of a system across multiple industries.
Instead of making ESF a completely new DSL that redefines every UML element, I think it would be much more powerful to instead treat it as an extension on SysML. This way the same block, or behavior, or interfaces, can be used both for the base functionality of a system, but also for the safety analysis. We could then create a profile extensions on SysML that provides safety analysis. For example, we could create a single main profile (or a few profiles) for FMEA and FTA (which seems to be the current focus), but also for the other safety analysis processes including hazard analysis. Then we could even create sub-profiles for different industries, like an ISO 26262 profile for automotive.
I hope I didn't misinterpret the metamodel conventions, but redefining all the elements with an S prefix seems like it wouldn't allow for this tight integration with other systems engineering activities.Dan_______________________________________________ esf-dev mailing list esf-dev@xxxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://polarsys.org/mailman/listinfo/esf-dev