David Lemmer Log

Mon Apr 25, 2022

SysML is the abbreviation for systems modeling language, which is a structured modeling language developed and maintained by the Object Management Group (OMG, https://www.omg.org/). SysML 2.0 is the new version of SysML currently under development and scheduled to have a full version release in 2022. The ongoing SysML 2.0 pre-release efforts are maintained at https://github.com/Systems-Modeling/SysML-v2-Release with 2 tools that allow practitioners to download and use the current pre-release (the tools are jupyter notebook and eclipse IDE).

SysML is used to describe systems of all types at the level of detail needed for its intended purpose. Methodologies such as OOSEM (object oriented systems engineering methodology , https://www.incose.org/incose-member-resources/working-groups/transformational/object-oriented-se-method) provide a structured approach to describe systems or systems of systems using SysML.

The above diagram starts to decompose requirements that support the goals of OSE by identifying areas of critical function or performance that must be upheld if the objectives of OSE are to be achieved. In the MBSE(Model Based Systems Engineering) process these requirements are derived by examining and decomposing stakeholder needs or aspects of a system which must be achieved to deliver the performance needed. These requirements will then be used to compare against system components and the properties they posses to verify that these requirements are met(satisfied). Doing this allows for the design of the system to be more easily understood as it is going through early design phases. The MBSE approach also enables trade study to be conducted more easily through the ability to compare their cost schedule and performance within one model. SysML also enables systems engineering practitioners to model the components of the system in an environment or context while considering the system as it is engaged in particular processes. These are contexts are described by capturing the relevant inputs to the system and processes are described and documented in behavioral diagrams. As this requirement decomposition is progressed updates will be posted here and Eclipse IDE SysM: 2/0 Script will be posted at the bottom of this post.

The other diagram types in SysML are structural and behavioral diagrams(See https://www.omgsysml.org/what-is-sysml.htm). These structural diagrams enable the sub-systems(organizations, tools, ect [things]) to be described. The behavioral diagrams are all about describing the activities, processes, and states(Verbs) the various structural elements will be engaged in. The combination of a methodology and the SysML language allows for systems to be rigorously and intentionally designed; simultaneously with the validation of business and stakeholder concerns tied back to the analyses conducted based on the parameters and processes of the system being designed.

Mon Jan 25, 2021

Hi David, I don't know what you are up to - but if you can, continue logging on your log.  I wanted to ask - could you produce a template for an Operations Manual for the Seed Home 2 Enterprise? As we discussed, core is building state of art houses at low cost - and training for builders and entrepreneurs. A critical enabling asset is the Operations Manual. We don't have a template for an ops manual. See 6.5 at https://wiki.opensourceecology.org/wiki/Seed_Home_v2#Enterprise, it's not well organized. Do you think you could come up with a template? This could be applied then to any enterprise, such as 3D printer production. See all prior work at  https://wiki.opensourceecology.org/wiki/Operations_Manual The point is to produce a turnkey guide that helps people start an OSE franchise. So this thus follows all the protocols of collaboration that we use. It would use all the best practices available, and would be substance for a highly replicable regional and international franchise. I put this on your log. MJ

Tues Jul 21, 2020

I think your effort could be best spent in your area of expertise, which is the process part. The design of the house modules is best left to those who have a lot of experience in that area. o, do you think I will be able to find the volume and connector information I need in the existing part libraries?

Somewhat, yes, but it has to be interpreted from the point of a design-builder, otherwise it's not buildable easily and cheaply.

Or is there a better place to look?

Also any feedback you have on the above is welcome and appreciated. Does this approach make sense? You are focusing on the technical detail. But the enterprise architecture is much broader than that. Role architecture is job one.

I am hoping to get a few things out of the modular breakdown, 1) this should be a repeatable process for future projects and helps to ensure interoperability across the enterprise by constraining[standardizing] interfaces. 2) each module can be given their own set of design goals, which should be based on performance goals and the primary value function of the module; This will help to guide design teams decisions during this event and similar breakdowns do the same for future events 3) having each module broken out in this way (interface constraints + performance goals) will help to inform about what technical specialties are ideal for the design team breakdown.

Technical detail of the actual house is a small part of the actual endeavor. The first thing is to lay out the role architecture, and the house modules fall out of that.

My previous experience here has been that we fit the expertise to the task by understanding the technical domains required to complete the task. These domains should be traceable from performance and functional requirements. So this is actually a part of what I am trying to get from modular breakdown.

Do you think you could do something regarding the larger picture of project management - ie, what does the literature say about the overall process for Product Design and Bringing a Product To Market?

There is quite a lot of material I've seen in my textbooks on this topic, covering tradespace analysis, stakeholder requirements/analysis, end user requirements and more. I will get after these topics with XE in mind, I think this will likely end up being a set of questions and processes to follow that help in answering "what is the primary value delivered to stakeholders?", "what is the primary value to the market?".

It occurs to me that I am resorting to old professional habits by e-mailing. Is there a place on the wiki where I should be performing these correspondences?

We want to start with all those roles in that. That to me includes things like - Legal, contracts, zoning issues and permits, marketing copy, web design, product strategy, product management, sourcing, logistics, video, documentation, distribution, production, economic analysis - the whole shebang.

One heuristic from the first SE lectures I'd attended comes to mind here : "In SE how do we eat the elephant? One bite at a time". So with a prioritization I can get after what is most relevant, for us (I think you'd laid that out in the previous sentences).

We are not developing a house. We're developing an enterprise that delivers the house to customers. Those are 2 very different things. The latter includes the former.

My current perspective is that I'm developing the processes that can be used to enable distributed, short time scale, product development. The ultimate product delivery must happen, but the bite I am chewing right now is the distributed scalable development process.

Thoughts?

Also, I put this on your log. Please post your thought process on your log so it's a public thing.

Marcin

V/r - David

Mon Jul 20, 2020

Hi Marcin,

Seeing the task breakdown timeline I think it makes the most sense for me to shift efforts for the time being to setting up design template models in CAD for each module of the micro house for XE. My thinking is as follows: 1) Almost all other modules when completed will reside within the volume constrained by the wall module (with few exceptions such as the rain catching gutter and cistern) 2) Therefore if we can, we should create reserved volumes to represent the space occupied by the other modules; these reserved volumes shall have any connections that allow them to interface with other systems pre defined, and, these volumes should be able to be re-arranged within the wall volume. 2.1) i think the electric (PV/grid), Door, window, bathroom/kitchen , Stove, water hookups, greywater, biodigester, modules will all require portions of the design that pass through the structural modules (walls floor roof)

Based on the above I want to ask if we should predefine the area of the the wall module? If not, will leaving this area unconstrained still allow for module interchangeability?

Based on the above reasoning I think the next tasks to get after will be as follows 1: Decide wall module dimensions 2: Build wall module template in CAD 3: Build other module templates in CAD that will define volume constraints and include all connectors that will allow interoperability with other systems 4: combine these together in a CAD assembly To act as the total project template

I think having this model would be a great tool for explaining the concept and also as something to approach crowdfunders with.

Please let me know if you think this is the right way to spend my efforts. Also, do you think I will be able to find the volume and connector information I need in the existing part libraries? Or is there a better place to look?

Also any feedback you have on the above is welcome and appreciated. Does this approach make sense?

V/r David

MJ sez:

You are focusing on the technical detail. But the enterprise architecture is much broader than that. Role architecture is job one. Technical detail of the actual house is a small part of the actual endeavor. The first thing is to lay out the role architecture, and the house modules fall out of that. Do you think you could do something regarding the larger picture of project management - ie, what does the literature say about the overall process for Product Design and Bringing a Product To Market? We want to start with all those roles in that. That to me includes things like: Legal, contracts, zoning issues and permits, marketing copy, web design, product strategy, product management, sourcing, logistics, video, documentation, distribution, production, economic analysis - the whole shebang. We are not developing a house. We're developing an enterprise that delivers the house to customers. Those are 2 very different things. The latter includes the former.  Thoughts? Also, I put this on your log. Marcin 

Tue Jul 14, 2020

• Discussion notes - David Lemmer