Conceptual Design
Contents
Protocol
Hint: A concept should be in the form of a cloud, collaboratively editable document such as a google doc which allows various parts of a design to be detailed.
- To write a concept, start a google doc based on the Google Slides Template - click edit below the template to get to the viewable document, and make a copy of the document
- Include Design Rationale information for as many aspects of the design as possible. The Design Rationale should frequently refer to OSE Specifications as the basis.
- Name that document Machine_Name_Concept. See Taxonomy for information on naming projects.
- Embed in wiki, in a page named Machine_Name_Concept. If there is a naming conflict, add some more words to your title, such as Machine_Name_Version#_Concept.
What is Conceptual Design?
The Design Concept is the first step of implementing the machine Requirement into an actual design.
The distinction between Requirement and Concept may be blurred - as a Requirement may be so detailed that it specifies actual technology/design choices.
In OSE's design language, an Integrated Requirement is one into which feedback from an actual build has already been provided. That is, if materials, calculations, or result data have been selected or obtained - then these can go into the Requirement - if they meet spec. 'Spec' means a certain level of predetermined performance.
In the limit of a fully-detailed Requirement - we have a concept.
In the limit of a concept being filled in with technical details - we have a Technical Design.
Thus in OSE work we propose the usefulness of Integrated Requirements - ones which embody learning from result data and other insights. The concept of integration is key to OSE work: input from numerous individuals who have experience in the CAD-BOM-Build cycle - and who understand from experience how to break the Iron Triangle.
OSE Philosophy
Jose Urra feedback: When I work I differentiate requirements from specifications. A design concept and its unfolding development is an attempt to specify the way in which requirements are met. Requirements can be stated without knowing in detail (specifically) how something is going to be achieved, they can be a set of goals or wishes that need to be verified. A concept is a model of a problem-solution unity more or less specified, or partially specified. Developing a concept thus, is the process of verifying the feasibility of the design concept. The rationale behind checking requirements is different from specifications. Requirements need validation - insofar as to check that a given requirement is needed, not if it is feasible in detail. Validation of a Concept detail is used when a concept is refined enough - as a minimum check to determine if a design detail is needed. Verification of a concept is the determination of its feasibility - such as by doing calculations.
MJ feedback: Calculations provide only a certain level of verification and are themselves not sufficient to prove that a design will work, because “All models are wrong, but some are useful”. Calculations must be verfied by integrated performance data - the actual results from a build. Regarding 'requirements do not need validation of feasibility' - this would not meet process spec for OSE. OSE's discipline involves validation of feasibility of what is to be built- otherwise the thing of interest may not be buildable. This is not to say that we don't create infeasible specification. We do all the time, as that is essential to pursuing BHAGs. However, once we gain experience, initial infeasible requirements are upgraded to verified and realistic requirements - corresponding to things that can be and are actually built. 'Bullshit requirements' are the initial non-feasible requirements that the team will cycle through and convert to feasible requirements. As progress continues, the team produces less 'bullshit requirements' and more realistic requirements. There is a danger: realistic requirements may not be ambitious or innovative. This needs to be addressed. We address this by a level of humility that says we do not know everything - so that our 'experience' does not lead us to losing our youth and creativity - and a commitment to extraordinary results. Humility and commitment allows us to produce realistic requirements that are still part of long-term moonshots.
Documentation Best Practice
Concept design requires verification. Calculations are related to a certain level of verification, and calculations are a separate Development Template (item #6). Concepts should be refined through review.
Thus, Review should be documented to facilitate learning as a team, including external teams outside the formal organization because OSE works openly.
How Does Conceptual Design Relate to Other Aspects of a Product Development Process?
Once we have defined Conceptual Design, we can proceed to further refinement of concept towards a technical design. Upon sufficient refinement, there is sufficient information to manifest the technical design in the form of 3D CAD. The Modular Breakdown step is where the concept can be refined further by examining the constituent modules. The Modular Breakdown is the best place to capture the transition from concept to the actual design. Once the actual design (3D CAD) is produced - we can do full Calculations including structural, thermal, fluid, and electromagnetic. Partial calculations can be made at the phase of conceptual design - with back of the envelope calculations just to get an idea of basic feasibility. All of these steps can be done at various levels of product-service system organization: the system, machine, module, and submodule (part) levels.
