4.0 - Design Process
The general process of designing a self-expanding industrial ecology is summarized as follows:
- Systems Engineering - We start by treating the whole production capacity, and any tightly coupled elements it interacts with, as a single system with functional elements, a boundary to its surroundings, and flows of resources across the boundary and between the elements. The complete system is successively broken down into smaller logical elements (functions) and the flows that connect them. Goals and performance are passed down to the smaller elements in such a way that the pieces add up to the desired total. This approach, called Systems Engineering, was first developed for complex projects that have complex goals, and the kind of production systems we are examining here qualify as such.
- Applying Design Concepts - In the process of setting project goals, dividing the system into functional elements and the flows that connect them, and identifying alternate designs to meet the goals, we incorporate the design concepts from section 3.0 where appropriate. If they do not provide a distinct advantage over conventional designs for a particular project, they do not need to be included. To these concepts we add some new design methods and tools adapted to self-expanding automated factories.
- Element Design - When the various elements of the system are defined to a suitable level of detail, then conventional design methods from the relevant engineering fields are applied. These include fields such as mechanical, chemical, electrical, and software engineering. The design requirements passed down to a single element will be a simplified subset of the overall project goals. A given element will typically involve multiple engineering fields at the detail design level. The various elements are then linked into a complete design (integration) and considered as a whole to verify they meet the total project goals.
Humans are not smart enough to optimize a complex design as a single pass through the above steps. Normally the design is developed as a series of cycles of increasing detail and optimization. A design baseline or version is recorded in each cycle to serve as the starting point for the next. When added cycles of refinement are not expected to gain as much improvement as the effort for another cycle would take, the design work then stops.
The remainder of section 4.0 will describe the above design process in more detail. We follow that with a series of specific design examples in later sections. The first example is a Personal Factory (section 5.0) which is locally owned, and supports most of the physical needs for several hundred people. Additional examples, an Industrial Factory, World Wide Factory, and designs for Remote Locations, are described in sections 6.0 through 8.0. The Industrial Factory is aimed at larger scale production of a more specialized range of products. The World Wide Factory is named after the World Wide Web, and considers a network of distributed production nodes that communicate and collaborate to produce desired product. The Remote Locations consider designs for difficult environment conditions and lack of an existing local economy. The different examples require different factory outputs and therefore a different design, but the design process for each can follow the same general process.
We expect that technology development and design will never really be finished, in the same sense that a home workshop or a manufacturing business are never done. Instead, the design cycle is first used to reach a useful level of productive capacity. At that point a "version 1.0" set of equipment can be built based on the current state of the design. The design cycle is then either continued to add more capacity, develop upgrades, or modify the designs for new locations, or halted temporarily and started up again at a later time. Reasons for additional design include feedback from real operating experience, and new technology developed outside the project. The development of initial and later versions is similar to the incremental development of software, and in fact a large part of a networked and automated factory will be software.
As noted briefly above, Systems Engineering is an interdisciplinary field of engineering that focuses on how to design and manage complex engineering projects over their life cycles. It evolved in the later half of the 20th Century as projects became more complex, and their design had to pay attention to more goals than just performance and cost. An expanding production system, with a Seed Factory and Mature Factory as start and end points, is complex both in the design at any one time, and the fact the design changes continuously over time. Therefore the Systems Engineering method is suitable for this kind of project. Systems engineering connects the work of more specialized fields like mechanical, chemical, and electrical engineering, but it does not replace them. The detailed specialty work still needs to be done. What systems engineering does is coordinate the process and the pieces of the design, so that the end result in total does what you intended.
In the Systems Engineering method, (Figure 3.0-2) a complex system is broken down into levels of simpler elements. Input and output flows are identified that connect the elements to each other, and with the System Environment, the external surroundings outside the system that interact with it. Those elements, in turn, are broken down further until you reach a level where the smallest are simple enough to be individually designed. The steps include:
- Identify Needs and MOE - The overall performance, cost, and other design goals for the system are called System Requirements. Requirements originate from an end user who has a need to be filled, or a design organization that observes a need and sets out to fill it. They specify in measurable terms what the system is intended to do.
- Perform Functional Analyses - The parts into which the system is divided, called Functional Elements, each perform a subset or step towards meeting these requirements.
- Allocate Requirements - The system requirements are broken down into component requirements, similar to how the functional elements are divided. This includes performance, operations, and maintenance for a complete functioning system. The component requirements are assigned as appropriate to the functional elements. This breakdown is called Analysis. The individual parts then each have their own assigned subset of the requirements to meet. Effectively they form a smaller and simpler subsystem within the total project. The intent is when you sum up the design and operation of the entire hierarchy of subsystems, they will then meet the original top-level goals.
- Model System and Alternate Approaches - Having assigned the requirements to the various levels of functional elements, the designers then consider alternate ways to meet the requirements for each part. This includes identifying the options, quantifying them in terms of numerical models, drawings, and other design information, and incorporating them into a complete model of the system.
- Optimize and Trade-Off Alternatives - The design parameters are adjusted and alternatives compared within the system model so as to select the best options.
- Synthesize and Document Configuration Baseline - The designs for the various parts are then put together, which is called Synthesis to make sure the design as an integrated whole meets the original system requirements. Finally the resulting design is documented in a version baseline.
For a complex system this process does not happen all at once, usually multiple tries and refinements are needed to get the best complete design. Tracking all the pieces and how they relate lets you make piecemeal changes and see how they affect the overall result. Figure 3.0.2 only shows the main steps. They are applied repetitively and in parallel at all levels of a design. On the whole it proceeds from top to bottom, but at any point a later step can feed back changes to update an earlier step, and better ideas can happen at any point in the process. This is why arrows are not shown connecting the steps - there would be too many feedback loops and the diagram would be messy. We describe the steps in more detail in the following sections, but they can only give an introduction to systems engineering methods. It is a well-developed engineering specialty, and we refer the reader to the many books and articles that cover it in more detail.
The general goal for the Personal Factory, as stated above, is "Locally owned, and supports most of the physical needs for several hundred people." A general statement like that is too vague to develop a design from. Thus the first step in the systems engineering process is to put that general goal in more specific and numerical terms. A design can then be measured against those specific values and you can tell whether you are meeting them or not. This step is called Requirements Definition. A particular project can have many different kinds of requirements, such as cost, performance, safety, quality, and others. Any feature which the end users would consider important can become a system requirement.
Diverse types of requirements are not directly measurable against each other, but different design options often affect several at once. For example, increased safety in a given option may also increase cost. To choose among design options with that affect multiple requirements, we convert the various requirements to a common scale and combine them to measure how well the design meets the full set of needs. A common measuring scale lets us choose the "best" option by adding up component scores for each requirement and picking the option with the highest total. The components that go into this scale are called Measures of Effectiveness, where each score measures how effective a design option is at meeting a particular requirement goal.
The set of system requirements should include anything the end user, or a design organization acting as a proxy for the end user, thinks is important and would affect the resulting design. It has the effect of narrowing the design options from the set of all possible designs to the ones that best meet the user's goals. Care should be taken to make the requirements technically feasible, but not to impose a predetermined solution. They should describe what you want the system to do, but not how to do it. This gives the designers flexibility to come up with new and better ways to reach the requirements.
Requirements typically fall into general categories, and are then individually numbered for tracking purposes. In the early industrial age, prior to about 1950, performance, cost, and schedule were often the only categories that mattered enough to design for. As systems have gotten larger and more complex, affecting more people, and end users have gotten more discerning in what they want, more requirement categories have become important. These include categories like safety, quality, and environmental sustainability. In theory, the systems engineering process can accommodate any number of requirements. The more of them you have, though, the more work is needed to analyze and meet them. So the minimal set should be specified to adequately cover what is important to the user.
Our chosen set of requirements for the Personal Factory is listed in Section 5.1. There is no "right answer" to setting requirements, they are a matter of end user goals and choices. If you select a different set, or put different numbers in the requirements, you just end up with a different design as a result. We think they are a reasonable set for an actual project, but they also useful as an example of a diverse modern requirements set. The requirements are written in terms of a Mature Factory which has reached design capacity. The Seed Factory, which will be the starting point for growth, is defined later. It will include what is needed for the first growth phases. The last growth phase results in the Mature Factory.
Like other parts of the design, the starting set of requirements are not permanently fixed. They can be updated in the course of development. However, the starting set should be as well determined as possible. Later changes will require re-working the design, which increases cost, so as a goal those changes should as few as possible.
Measures of Effectiveness
As noted previously, desired features are often in opposition. For example, higher performance and reliability often come at the expense of higher cost. The question is then how to optimize a design, or choose among alternate technical approaches, when multiple desired features change at the same time. Systems engineers use a quantitative set of measures to account for these disparate features. Like requirements, they are derived from end user desires as to what would be "better" when comparing one design over another. The measures are usually strongly related to the requirements set. Since different features typically have different units of measurement, they need to be converted to a common measuring scale. This is done by formulas that convert each different value, such as cost or performance, to a score. These scores are given relative weights based on their importance to the customer. The weighted measures can then be used in a single mathematical model or formula to find a total score. When the component values vary across different designs, the one that results in the highest total is deemed to be "better", and is selected. Not every requirement has a related measure. Some are absolute and have no variability. This may come from outside constraints like laws and regulations, or the requirement is a basic feature which must be met, or the design would not meet it's intended purpose. In these cases, any design option must fully meet the fixed requirements, and the ones that are variable are allowed to adjust as needed.
The value scale is often in a range such as 0 to 100%, or 1 to 10, but this is arbitrary. What is more important is a definite conversion from a measurable feature to a scoring value, and the relative weights and method of combining them to a total score. As an example, a value of 0% might be assigned to a factory output of 15 tons/day, and 100% to an output of 45 tons/day, with a linear scale in between, and the output rate given a weight of 30% in the total score. The scoring system is a mathematical model of the customer's desires for the system. It should span from what they consider unacceptably low values to highly preferred high values. Getting a customer to define what they consider good or bad in such detailed numerical form is often difficult. It removes their freedom to choose what they personally prefer in a design in spite of the best engineering solution. It is necessary, though, if you really want an optimal answer. At the least this process makes it obvious when the customer is overriding the engineering process.
It should be kept in mind that a particular design solution may not be "good enough" in terms of of its score, either by itself, or when compared to existing systems. The comparison to existing systems is done by including them as one or more of the alternative designs being scored. Too low a score indicates no design is good enough to satisfy what the end user wants, or is sufficiently better than what exists already to choose it. In that case the proper answer is to stop development of the new system and stay with the existing ones. One option is to reassess the original requirements. Often the cause of a low score is not enough performance improvement relative to cost, but other measures can give such a result. A scoring system can also be used to determine in advance how much improvement would be needed to justify a new design. That can become a goal for research and development. Building a new design would then wait until the research reaches those goals. Engineering work to establish goals and define research needs, but not directed at immediately building a system to satisfy a need, is called Exploratory Design. The examples in this book are partly exploratory, to help understand what can be done with Seed Factories. They are also tutorial as far as showing how such designs are made.
Applying Design Concepts
A number of design concepts were identified in section 3.0. We want an organized process to apply these concepts into our design. We do this via a Concept Application Analysis which takes each concept and considers where among the systems engineering steps and design data a given concept will be used. A possible outcome to keep in mind is a particular concept may not be used at all on a given project. The analysis records where the concepts are applied, and the reasoning behind those choices. The actual application is via imposed requirements, functional elements, design checklists or design features incorporated into the design data.
Once the system elements are sufficiently well defined, their individual detailed design can proceed by conventional methods. There are numerous books that cover the various fields of engineering, so we will not reproduce all their details here, but rather provide a general outline and some reference sources.