Last week I initiated a discussion on what is feel is a void in product offings from modeling and simulation software vendors for a true conceptual engineering development workspace. As promised, I'm providing an example that should help with understanding where I am coming from.
listen to this story
In last week’s blog (Engineering Where the Most Opportunity Exists) I talked about how I don’t feel there is a commercial offering to support multi-user collaborative workspace to support conceptual engineering for New Product Development. As promised here is an example situation that should help with understanding where I am coming from:
Problem Statement
The Loew Technology Company is trying to win a bid with an OEM for a contract for a Stabilizer System for a mobile platform. The requirements are as follows:
| Requirement | Value | Unit | |
| Target Cost (system) | >= | CO1 | $ |
| Actuation must consist only of an electric actuator (one per station) | |||
| Voltage (supply) | Nom | V1 | VDC |
| Tol +/- | V1a | VDC | |
| Power peak | <= | kW | |
| Cycle time (stowed position w/ landing foot attached – ground engagement at minimum height – lifting to max height) | T1 | sec | |
| Design must utilize prescribed mounting interface (common front & rear) | |||
| Design in stowed condition must not violate prescribed package space (unique front to rear) | |||
| Mass (each) | <= | M1 | kg |
| Design must incorporate a removable landing foot with a spherical joint connection (common) | |||
| Foot print area | >= | AREA1 | |
| Articulation | >= | ANG1 | |
| Mass | <= | M2 | |
| Tie-down provision IAW XXX must be utilized | |||
| Tie-down loading as shown (mechanism in stowed position) | F1x | kN | |
| F1z | kN | ||
| Deployable height (min) | H1 | mm | |
| Deployable height (max) | H2 | mm | |
| Foot loading (applied at centroid of ground contact area of landing foot, any height) | F2x | kN | |
| F2y | kN | ||
| F2z | kN | ||
| Platform mass | = | M0 | kg |
| many more that we won’t consider at this point |
Right off the bat it should be recognized there are components (both physical components that will eventually become product, and non-product geometry like the keep-in zones for the stowage space), joints or interactions, states (stowed, tie-down, deploying, leveling, retracting, transport), and quantities that must be extracted from simulations (mass, peak power, cycle time, stress, area, interference checks, etc.). It should be clear that we are going to have to be able to at least conduct the following analyses just to get started developing concepts (and we need multiple concepts):
- Mechanism synthesis (a process of geometrically or analytically developing a mechanism that meets requirements – typically position)
- Static structural analysis (joint and member forces can be calculated from simple statics – good place to start)
- Conceptual geometry (initially based on satisfying success criteria from 1 & 2; need inertia properties for 4)
- Dynamic simulation (required to cascade specifications to actuator design and compute power consumption and cycle time)
Geometry
In order to set ourselves up for success we need to create and manage the basic geometry from the requirements (prescribed and inferred) and ensure we have the ability to instrument the design to measure the geometric quantities. I see it like this: States with the mechanism retracted (Stowed, Transport, and Tie-down states) as shown in Figure 1 and the state with the mechanism deploying as shown in Figure 2.
Figure 1: Tie-down state with “keep-in” package space geometry shown
Figure 2: Mechanism deploying state
System Model
The system model must initially at least have these components (common to any concept) as shown in Figure 3:
Figure 3: System description (Block diagram)
Let’s Engineer!
It is only at this point do I feel that we have enough context to start creating any concepts. I’ve seen engineering teams waste a lot of time developing concepts before they understand the basic requirements. With this type of disciplined approach to capturing the requirements we can now start exploring the design space by looking at different concepts and also parametric manipulations of each individual concept.
Everyone says they want to “think outside the box,” but if you will excuse my turning on this popular cliche it is only inside the box where there is a valid solution. This is a multi-disciplinary problem and probably requires engineers with multiple skill sets (mechanism, structures, mechanical design, dynamics, electrical systems, etc.) to be involved simultaneously to propose and refine the concepts. This is why the workspace must allow for multiple contributors.
Don’t forget this is just to get system concepts underway; we will still need to mature components and sub-systems on the promising looking concepts. For example: we can cascade the requirements for the electrical actuator down (stroke, speed, forces, etc.) and look for a COTS or configurable solution or will this require a custom actuator? Additionally, I may want to perform topology optimization on the structural components (certainly anything that is not idealized as a two-force linkage). Any of the pins, busings, and two-force members we might feel comfortable sizing initially with closed-form equations to start.
Once we get this roughed out we need to continue to iterate and refine the concepts. With concept geometry now for components we will have more realistic values for masses, inertia, volume, etc. replacing the initial guesses we have to make. Our simulations probably were only looking at the kinematics, dynamics, and structural considerations in a plane. Now with some geometry in the depth direction, we can add side-load and mis-alignment that we would expect to see (don’t always expect your customer to tell you all this either, you still need to use good engineering judgment; the requirements will not specify everything).
So Am I the only one that thinks this way?
