4.0 - Design Process

General Process

The general design process for self-expanding production systems like seed factories includes several major elements:

Systems Engineering - The Systems Engineering approach was previously developed for other complex projects with multiple goals. Seed factories, and the growth paths they follow, qualify as complex, so we adopt this method of managing complexity. We start by treating the whole production operation, and any tightly coupled elements it interacts with, as a single system. The system contains 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. System goals and performance levels are passed down to the smaller elements in such a way that the pieces add up to the desired total.

Applying Design Concepts and Ideas - We incorporate the design concepts from section 3.0 where appropriate into 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. This includes system measures particular to self-expanding systems from Section 3.0, and motivations and economic factors from Section 3.1. We also apply technical concepts like conservation of flows and modular designs from Section 3.2, new ideas from Section 3.3, and our reference architecture from Section 3.4 if they are useful. If they do not provide a distinct advantage over conventional designs for a project or its parts, they do not need to be included.

Element Design - When the various parts of the system are defined to a sufficient level of detail, then conventional design methods from the relevant engineering fields are applied. These include mechanical, chemical, electrical, software and other fields. A given element will typically involve multiple engineering fields at the detail design level. The design requirements passed down to individual elements will be the applicable subset of the overall project goals. The individual elements are then linked into a complete design (integration) and considered as a whole to verify they meet the total project goals. There are many books and information resources that cover the various fields of engineering and design, so we will not reproduce all of that here. Instead we will discuss it in general terms in sections 4.1 to 4.4, and provide links to more detail.

A design team, however skilled, is not capable of fully optimizing a complex system as a single linear process using the above steps. Normally the design has to be 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 more cycles of refinement are not expected to gain as much improvement as the effort would take, the design work can then stop. The project then transitions to production, construction, and operations. The entirety of a large project does not have go through all the steps from design to operations at the same time. Parts of it can start and reach completion at different times as needed. Staggering the work in time can reduce peak funding and staff needs, and allow some benefits to flow back from the completed parts. This is particularly true for self-expanding systems. An Initial Operating Capability, in the form of an operating seed factory starter set, can start producing useful products and income while later expansion phases to reach Full Operational Capability are designed and built.

In some cases the design work stops at an earlier point than the optimum set by diminishing improvements. Reasons include lack of sufficient resources, speeding up time to market, or producing a prototype for testing. In those cases repeating or completing the design process provides an updated or improved system. The remainder of Sections 4.0 to 4.4 will describe the above general process in more detail. We follow that with a series of design examples in later sections:

Personal Production (Section 5.0) - In this example, the machines are typically small, for home improvement and hobby scale uses, which makes them affordable. Individual machines or groups of them can be located in homes or community workshops.

The "MakerNet" (Section 6.0) - Here, a distributed network of people collaborate and electronic links coordinate the work to make products for each other, or help build new network nodes. New sites within a regional location, and distinct locations in different areas, start with partial equipment sets. They grow with the assistance of existing network nodes to small business scale, supplying products and services to local communities. The network of locations are in already developed and populated areas which can supply the things internal production can't.

Industrial Production (Section 7.0) - In this example, starter sets of machines grow by scaling, making parts for larger and larger machines. This leads from smaller starter sizes, to commercial and then industrial scales. At smaller scales it is feasible to gather a full range of production machines at one site, and make a wide range of products. At larger scales it becomes more difficult to locate all the equipment in one place. So in this example the equipment and their operators become more distributed and specialized on multiple sites. Commercial and industrial scales mean the outputs are well beyond the personal needs of the operators and their local community, and serve larger markets.

Remote and Difficult Locations (Section 8.0) - Current civilization is mostly limited to a thin layer on 13.5% of the Earth's surface. The remaining area consists mostly of oceans, deserts, and ice caps which are barely used. Aside from a few places like mines and city centers, we rarely depart more than a few meters in a vertical direction from the surface. This example applies self-expanding production methods to tap the unused physical space and resources, which are currently too difficult or expensive to access. In particular, access to increased energy sources allow more recycling and sustainability. Distance and difficult conditions means we emphasize remote operations, and setting up complete starter sets. These locations don't have the benefit of existing infrastructure and population at first.

These examples, along with necessary precursor research and development, can be linked in a sequence to form a continuing program. Such a program has no specific end point, but rather applies self-expanding systems to continually upgrade and expand civilization. The outputs from each example can then used as inputs to the next, in an unbroken growth process. The needs of each example, and making them a linked sequence, requires new production outputs and therefore new designs for each program phase. The design process, however, can follow the same general path for each. A previous round of work on the seed factory concept was done on a Community Factory which is locally owned, and supports most of the physical needs for several hundred people. This falls somewhere between personal and commercial scale. The earlier work has been moved to Section 2.3.2.9 of the Seed Factory Project workbook for reference.

All of the above examples are on Earth. But the laws of nature are the same everywhere, and our knowledge of science and engineering applies to the space beyond Earth just as well as here. So self-expanding production can be applied to space too, which is currently more difficult and expensive to access than places on Earth. The space environment, and systems designed to operate there, are different enough that a separate book on that subject makes sense. Additional design examples for space, and a continuing program to access the resources found there, is therefore included in Part 4 of the Space Transport & Engineering Methods wikibook.

We expect that technology development and element design will never really be finished, in the same sense that a home workshop or a manufacturing business are never finished and become static. Instead, the design process 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 that design. The process may then either continued - to add more capacity, develop upgrades, or modify the designs for new locations. Alternately, it may be halted temporarily and started up again at a later time. Reasons for new design work, besides new locations, industries, or sizes of equipment, 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. In fact, a large part of a design that uses networked and smart tools will actually be software.

Systems Engineering

As noted briefly above, Systems Engineering is a method for managing complexity in engineering projects. It is an interdisciplinary field of engineering that focuses on how to design and manage projects over their entire life cycles, from concept to final disposal. It evolved in the later half of the 20th Century as projects became more complex, and their designers had to pay attention to more goals than just performance and cost. A self-expanding production system, with seed and mature states, and all the growth steps in between, is complex both at any point in time, and due to the design changing 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 parts of the design work, so the final result in totality does what was intended, and minimizes unwanted side effects.

Like other well-developed branches of engineering, there are a number of textbooks, educational programs, and professional organizations related to this subject. An online collection of systems engineering information can be found at the BKCASE website. The US Library of Congress catalogs over 2000 works under the phrase "Systems Engineering". MIT offers a course on the Fundamentals of Systems Engineering, and other related courses through their OpenCourseWare project. The International Council on Systems Engineering is the largest technical society devoted to this field, with over 10,000 members.

Figure 4.0-1. General Systems Engineering Steps.

In the Systems Engineering process, (Figure 4.0-1) a complex system is broken down into successive 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. Each element, in turn, is broken down further until you reach a level where the pieces are simple enough to be individually designed. A summary of the process includes:

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. Measures of Effectiveness (MOE) express how good or bad a given design is on explicit scales. For example, "minimize cost" is often a project goal, but for a mobile phone USD 300 might be an ideal target and USD 600 would be unacceptably high. The cost measure can then be scaled linearly between those points, and traded against other goals.

Perform Functional Analyses - The parts into which the system is divided are called Functional Elements. Each perform a subset of, or step towards meeting the system requirements. Functions identify what is to be done, but not yet how to do it. Leaving out the "how" at this point avoids prematurely selecting a solution before considering the various options and their interactions.

Allocate Requirements - The system requirements are broken down into component requirements, similar to how the functional elements are divided. The component requirements address all the performance, operations, and maintenance needs for the complete functioning system. The component requirements are assigned as appropriate to the functional elements. This breakdown is called Analysis. The individual elements 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 whole system.

Optimize and Trade-Off Alternatives - The design parameters of the elements are adjusted, and alternative choices compared, within the system model. Each variation produces different values for cost, performance, and other measures of goodness. If the right measures were selected in the first step, the "best" design means "highest combined score across all the measures". An objective scoring method helps remove personal preference or bias from the design process. Such personal leanings will still exist, of course, but at least they are made explicit.

Synthesize and Document Configuration Baseline - The designs for the various parts are then put together, which is called Synthesis. This makes sure they fit together as a cohesive whole, and total design meets the original system requirements. Finally, the resulting design is documented in a version baseline.

For a complex system this process does not happen once in a linear sequence. Usually multiple tries and refinements are needed to get a good complete design. Tracking all the pieces and how they relate lets you make piecemeal changes and see how they affect the overall result. Figure 4.0-1 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 hard to read. We expand on the process summary in the following sections, but they can only give an introduction to systems engineering methods. We refer the reader to the many books and articles that cover it in more detail. Note that a system can be "over-engineered". At some point doing more optimization and design refinement does not gain enough improvement to justify the effort. At that point, design can be considered complete, and the project moves on to production and later stages.

Requirements Analysis

A general goal for the Personal Production example, might be "produce products and outputs for the owner/operators at home improvement and hobby scale". A general statement like that is too vague to develop a design from. So the first step in the systems engineering process is to put general goals into more specific and numerical terms. A design can then be measured against those specific terms 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 choices often affect several at once. For example, increasing structural strength can improve safety, but also increase weight and cost. To make choices in this situation, we convert the various design parameters to a common set of units, such as a point scoring system. This lets us choose the "best" option by using the component scores in a formula or table, and picking the one with the highest final score. The components that go into this scale are called Measures of Effectiveness, where each component measures how effective a design option is at meeting a particular requirement goal.

Requirements Definition

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. Prior to about 1950, performance, cost, and schedule were often the only categories that mattered enough to explicitly design for. As systems have gotten larger and more complex they began affecting more people, and end users have gotten more discerning in what they want. So more requirement categories have become important. These include items 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 that adequately covers what is important to the user.

Our chosen set of requirements for the Personal Production example are listed in Section 5.1. There is no "right answer" to setting requirements, they are a matter of putting end user goals and desires into measurable form. So they originate from people's preferences, which are variable. You can select a different set, or put different numbers in the requirements, and then end up with a different design as a result. We think the ones given are a reasonable set for an actual project, but they are also useful as an example of a diverse modern requirements set. The requirements are written in terms of the mature system which has reached design capacity. The seed or starter set from which growth begins, is defined later. Working backwards from the end goal is easier than "forward design", because each growth step has a defined end point. The other direction, growth from a starter set, has many possible paths, and it is not obvious which one to follow. Working backwards narrows the choices to the ones that lead to the desired end point.

Like other parts of a design in progress, the starting set of requirements are not permanently fixed. They can be updated when new information provides a reason to. However, the initial requirements should be as well developed as possible. Later changes will require re-working the design, which increases cost. As a goal, requirements changes should as few as possible.

Measures of Effectiveness

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 features change at the same time. Systems engineers use a quantitative set of Measurements to account for this. Like requirements, they are derived from end users 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 are converted to a common measuring scale so they can be compared. This is done by formulas that convert each different measure, 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 design options, 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 can happen with outside constraints like laws and regulations. When the requirement is a basic feature which must be met, or the design would not meet it's intended purpose, it becomes a simple "yes/no" question and not a variable scale. 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 scales for each feature are 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 aspect of the system 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 greatly 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. When the end users are consumers, society at large, or in the political sphere, direct user input may be difficult or impossible, or intentionally misdirected. In those cases, studies need to be performed to determine the proper requirements and measures, despite lacking suitable user inputs. A hypothetical example is automated medicine using robotics and AI to deliver services. It may vastly improve the quality and cost of services. But the end users generally don't know enough about the subject to provide input. The medical professionals, insurance, and political systems who do have the knowledge or provide funding have other interests, like preserving their income or a particular political philosophy. Therefore independent studies are needed in such cases to determine the best technical solutions and how to implement them.

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 the new design is not good enough to satisfy what the end user wants, or is not sufficiently better than what already exists. Often the cause of a low score is not enough performance improvement relative to cost, but other measures can give such a result.

A future project example that is not good enough is the original space elevator concept, reaching 60,000 km from the ground to space. No current or projected materials can build such a design where the economics make sense. In that case the proper answer is to stop development of that particular concept and stay with existing systems for the time being. Work can turn to finding new concepts and approaches that would bring better results. In this case a much shorter elevator, not attached to the ground, with moving parts, and a sub-orbital vehicle to reach it, results in an economically viable approach. One option when the design is not good enough is to reassess the original requirements. This means going back to the users or customers to find out what changes they will accept.

A scoring system can also be used to determine in advance how much improvement would be needed to justify a new design. That improvement then becomes a goal for research and development. Executing the project would then wait until the research reaches those goals. A current example is for electric cars. Batteries first needed to reach an acceptable capacity to weight ratio, number of charging cycles, and cost before it was feasible to use them in car designs. This type of engineering work, to establish goals and define research needs, but not directed at immediately building a system, is called Exploratory Design. The examples in this book are partly exploratory, to help understand what currently can be done with self-expanding production systems, and what further research and development is needed. They are also tutorial as far as showing how such designs are produced.

Applying Concepts and Ideas

A number of concepts and ideas were identified in Sections 3.0 to 3.4. Since some of these will feed into project requirements, we bring them up at this point, but they may apply at later points in the design. We want an organized process to apply them when needed. We do this via an Applications Analysis during the Concept Definition stage of a project. This is normally the first stage of a project's life cycle. The analysis takes each concept or idea and considers where among the systems engineering steps and design data a given concept can be used. A possible outcome for a particular idea is not to use it at all on a given project. The analysis records where the concepts should be applied, and the reasoning behind those choices. The actual application of a concept is via imposed requirements, new functional elements, or design options, checklists, or features that are incorporated into the project. This will be shown in more detail for the later examples. We provide a preliminary version here for our reference architecture to show how such an analysis is structured. It lists the various concepts and ideas, and describes where or how they are included.

System Measures

These measures were listed in Section 3.0. The first group are ratios relative to design features of the factory:

Closure Ratios (CR) - These are the percentage of a factory, its end products, or both combined, which it can make internally, in terms of parts count, mass, value, or other key factor. Whatever is not made internally is supplied as inputs from outside the factory. As a factory grows and adds new equipment the ratio can change over time. Achieving high closure ratios is interesting intellectually, but not an end goal in itself. The usefulness of this measure comes from how it affects factory initial and operating costs, which people do care about. Presumably high closure ratios lead to lower costs, but this relationship must be demonstrated to be true. If so, designers can track closure ratios in a similar way to how weight and cost are tracked.

Output Range (OR) - is the ratio of possible factory outputs to factory elements by the same measure, such as mass, counting one copy each of outputs and elements. It measures diversity of products vs complexity of the factory. When the outputs include parts of the factory itself, they are also counted in this measure. Higher OR should provide better factory economics through more diverse outputs, and better growth through more self-production.

Expansion Range (ER) - is the ratio of outputs that can be used to expand the factory divided by those of which it is made, in units of mass, or process, parts, and materials counts. It is a measure of factory diversification, meaning how many new things the factory can do relative to a starting point. A higher ER implies a smaller starter set and more possible outputs. Like closure ratios, output range and expansion range can be tracked on spreadsheets and reports derived from design data.

The next group are quantitative production outputs in total amounts and rates. They measure how productive a factory is, and therefore economic value and growth rates:

Production Ratio (PR) - is the total output in a quantity of interest (mass, energy, parts count, monetary value, etc.) over its life, versus that value for a single equipment item or the factory as a whole. An example is PR(energy), also known as "Energy return on energy invested", or EROEI. This is the energy produced by an item relative to the energy required to make that item. Production ratios should be significantly greater than 1.0 for a system to continue operating and be economically viable.

Production Rate (P/t) - is the production ratio PR divided by a time unit, such as hours or years. Where PR measures how much output can be made in total, P/t measures how fast it can be done. Higher rates should lead to better economics and faster growth of a factory. Production measures are first estimated from design data, then measured on prototype and final equipment in operation. These measures can be compared to those for conventional non-self expanding production. Favorable comparisons provide a motivation to develop and build this kind of production system.

The third group are growth ratios and rates relative to a starting point. They measure how much a factory can grow and how fast it can grow. These are of economic interest, and the ability to meet output goals. They may be included as project goals and requirements, then tracked through design estimates and actual performance.

Growth Ratio (GR) - This is the final capacity of the factory, in units of interest (mass, floor area, output per year, etc.) relative to a starting point.

Growth Rate (G/t) - This is the fractional change in capacity per time unit, typically years. Growth rates are common measures in economics and investment.

The last group from Section 3.0 are efficiency measures. Standard engineering efficiencies are useful output divided by total input. For example, a sawmill's conversion efficiency is the mass of lumber output divided by the mass of logs input. Such efficiencies are normally calculated and tracked in engineering design, since higher efficiency means less wasted energy and materials. For an integrated factory that uses outputs and wastes from one process as inputs to another, and recycles materials, we can look at total system efficiency of the factory as a whole. This would be a new measure to set as a goal and track during design and operation. A new set of measures are Renewable Efficiencies, which are the percentage of energy and materials from renewable sources. These have begun to be set as government and business goals in recent years, and may be included as a project goal or requirement, then tracked during design and operation.

Motivations and Economics

Motivations and economics are social factors that cause people to be involved in, and contribute resources to, a project. They were discussed in Section 3.1.

Motivations - These are the reasons people and groups take action and do things. For projects like designing and building self-expanding factories they need enough motivation to provide the labor, materials, and other inputs required. Motivations can be studied at the individual level, where they may involve satisfying biological needs and personal desires. They can also be studied at the group level, such as trading networks, cooperatives, and corporations. Groups have motivations separate from those of their members. Motivations can be incorporated into a project in the early systems engineering steps, where needs, goals, objectives, and requirements are set. In later work, if the results of design are compelling, they are presented in reports and presentations to motivate them. Taking action requires knowing an action exists and is possible, so it must be presented to people who can then take them.

Economics - Economic reasons are known to be powerful motivators to take action, use available inputs, and provide goods and services. People have physical needs and personal desires. So they are motivated to satisfy the greatest amount of them for the least effort. This allows them to have the most satisfaction for the most time. For many people the most efficient route available has been to trade their time and skills for an intermediate good, money. Money, in turn, can be traded for many of the things they need and want. This allows them to specialize in things they are good at, and work in groups to produce goods and services more efficiently.

Trading labor for money is a linear process, you get a set amount of money for a give amount of labor. The concept of Exponential Growth (Compound Interest) applies a growth increment per time on a growing base amount. The returns are no longer linear, but accelerating with time. People have a strong motivation to find such accelerating returns and put part of their labor or money into them, since they can later satisfy more needs and desires from the larger returns. If self-expanding factories can demonstrate high growth rates, then we can expect people and groups to put effort into them. How to incorporate this into a project is to calculate estimated growth rates during the design stage, then demonstrate them in practice when examples are actually built. Informing people of these growth rates should motivate them to take advantage of the high returns.

An ever growing factory that does not produce useful end products or income is not very desirable. Therefore the total output is split between internal use for maintenance and growth, and external use by the owners or for sale. The goal is to maximize satisfaction by optimizing this division of outputs. People's needs and desires are variable, including for the same person at different times, and external circumstances like materials cost or new technology can also vary with time. So the division of production outputs can't be set during design and never change. To handle it, a planning process is used to project what outputs are needed and adapt the factory to meet them. This would start during design, and continue throughout operations.

Margins, operating costs, and productivity should also be estimated and monitored on a continuing basis. This includes internally for the production system, and externally for new equipment, technology, processes, and types of organization. When better ways are identified, they should be incorporated as upgrades or replacements. It may happen that older factories are no longer viable and should be decommissioned. Both project motivations and economics are applied by assigning staff to develop and track them during the life of the project.

Technical Concepts

Technical concepts related to self-expanding production systems were listed in Section 3.2. We apply these ideas as follows:

Conservation of Flows - Conservation of mass and energy laws are a standard part of science and engineering, and are frequently used in design. For example, the air and fuel flows into a jet engine must equal the exhaust flow out due to conservation of mass. Usually the laws are applied to individual machines or processes. It has not been common to track all the types of inputs, outputs, and flows across the parts of a complex system. We apply the principle across all design and operations to help capture all the inputs and outputs and find opportunities to use what would otherwise be wastes.

Systems Approach - This is already included by choosing the systems engineering method to provide structure for and coordinate the design process.

Modular Design - We can't predict in detail what types of future outputs people will want to satisfy their needs and desires. We also can't predict how many people, as owners and customers, will want those outputs over time. Therefore we want our production system to be flexible to grow and adapt its outputs as needed. We apply the modular design approach during the early stages of engineering, by setting standard sizes and spacing for modules, shared interfaces and protocols for connecting things to each other, and automating the process of making and installing new modules, or rearranging them when needed. Therefore capacity will more closely follow demand.

Local Resources - Material resources, like metal ores, are typically found in high concentration in a few places. High-grade ores require less work to extract, but then require more transportation to the places they are used. Self-expanding production that builds its own energy sources can shift the balance to lower-grade ores or even common rock. These occur in more places, and reduce transport distances. This allows a shift from fossil fuel-based transportation, which has a high energy density but unfortunately a CO₂ waste problem, towards alternatives like electric transport. Waste dumps and scrap materials often represent usable grade ores, and with more energy available they can also be used as sources. Both decreased transportation and recycling improve sustainability, which is a major goal. How the idea of generalized resources gets applied is during design, by placing requirements and scoring measures in place that enable choosing those types of resources, rather than scarce resources with unwanted side effects.

Cyclic Flows - We have already mentioned recycling by exploiting waste streams as ores. We want the benefits of lower outside resource requirements and increased sustainability, so in addition we can incorporate recycling by design. This is implemented by design requirements to examine all outputs, both useful products and wastes, for reprocessing and reuse elsewhere in the system, and including design features to make this easier.

Distributed Operations - Remote operations reduce the need for people to travel to a work location, and to supply facilities like parking space. Distributed production closer to where people want the outputs further reduces transport needs. These can be applied by requirements to consider remote and distributed work as design options. Self-expanding networks can maintain the remote and distributed features as they grow.

New Ideas

Ideas developed since the original 1980 work on seed factories were listed in Section 3.3. We apply them as follows:

Resource Accounting - This applies the idea of conservation of flows to an entire system and all its parts. It adopts the tools of financial accounting, such as balancing accounts and spreadsheets. But it is applied to all types of resources, and not just money. How it gets applied is by setting up resource tracking from the start of design, and continuing throughout the life of a project.

New Software Tools - Existing office and engineering software are used in the normal course of projects, but some new ones will be useful for self-expanding projects in particular. These would have to be custom-designed, or adapted from existing software as part of the R&D portion of a project. A Process Compiler would take design files that include data on dimensions, materials, and assembly instructions. It converts them to a series of operations, to be done by an automated factory's machines and the people who work there. When a factory is constantly growing and changing, so will the production flow for a given product. A process compiler will mostly automate the planning in the same way a software compiler automates the conversion from a programming language to executable code. Like software development, process flows will likely benefit from some hand-optimizing of the detailed steps, so we do not expect process planning to be fully automated.

Additional software will be needed to control individual machines, and to network them so that commands and status can be delivered. Augmented reality and telepresence were not feasible in 1980, due to the less developed state of computing and communications, but are feasible today. They can be applied to design and manufacturing by displaying 3D designs in the actual factory space, showing work tasks during operation, and immersive displays for remote operators. The equipment and software in this area are in rapid development, so how much custom development will be needed is an open question.

Project Evolution - Early ideas for self-replicating factories assumed the first factory made an exact copy of itself, and was 100% automated in doing so. This simplified the growth process to doing the same overall task many times, producing many factory copies. But this approach ignored the details of what final products would be made, and made the factory design very complicated. In our current work we start with a much simpler starter set of equipment for a seed factory. This evolves to a full capacity factory by adding different machines than were in the starter set, and scaling existing types in size, in addition to making exact copies of the original equipment. The evolution can be broken into smaller steps, like adding one new machine at a time, or one attachment or accessory to an existing machine. This type of growth allows deferring design for later growth stages until needed. Since particular end products are the final goal, planning the growth works backwards from the equipment needed for those end products. In turn, earlier sets of machines are identified that can produce the final set, and so on back to an original starter set. Each step in the growth is then a simpler design problem than a fully self-replicating factory. In planning the growth sequence, some items can't be made by the available equipment. So outside supplies of machines, parts, and materials are added as required. The amount of outside supply should decrease as the growth proceeds.

Universal Factory - This idea is a factory capable of producing any known product when fed the design files as an input. It is a new idea so far as we know, and there are open questions about what is needed for universality and whether a self-expanding factory can grow to become universal. For now we would devote some research effort to this idea, and see if it proves useful.

Reference Architecture

We described a reference architecture for self-expanding production systems in Section 3.4. How we apply this architecture is to use it as a starting point for each of the examples in this book, and for other projects. Future work on these examples and projects may identify improvements and updates to apply back to the reference for use in later work.