The Seed Factory Project

2.2 Requirements Definition

In Section 2.1 (Initial Project Definition) we establish a high level expression of the project objectives in the form of general verbal goals, system properties, levels of technical performance, and similar statements. We will also identify some value preferences which describe what a better design is from an overall civilization point of view. Examples include "minimum cost", "minimum waste output", "maximum safety", and "maximum efficiency" (this hasn't been done yet). We divided the goals and objectives into a number of project phases, and described an operational concept and initial baseline design to meet the objectives.

In this section we take that starting information, make it more specific, and break it down into lower level requirements. The project tasks are divided into tiers of logical elements called Functions, and the requirements are assigned in tiers to the lower levels. The assignment ensures that somewhere in the project all the top level goals are met. At the lowest tier, a small enough subset of the requirements become the detailed design conditions for that function. A detailed design can then be done to meet the conditions with a reasonable effort. In general terms, the requirements say what that element is supposed to do, and the design produced in response is the how it will be done. More than one function can be assigned to a given design element. For example, a multi-function printer can perform the distinct scan and copy functions.

2.2.1 - Project Requirements Development

The sequence of work is to first divide larger project tasks into functional elements, then divide and assign the requirements. We need to know what the functions are first in order to properly do the division and assignment. In general, dividing something into smaller pieces to understand it is called "analysis", so our first step is called "Functional Analysis".

2.2.1.1 - Functional Analysis

There are many possible ways to divide a large project into smaller pieces. If large amounts of people and time are available, you can develop multiple breakdowns according to different system concepts and alternatives. We are starting with a small staff and limited time, so we are taking the approach of a single breakdown with limited alternatives, chosen according to our best understanding. If we gain more staff, we can come back later and investigate more concepts and alternatives.

Functional Flows - The project as a whole, and individual functions within it, have flows that enter and leave them. Flows can be any type of resource, energy, or information. Some flows are transformed by the function. For example, an incoming block of metal may be transformed into an outgoing finished part. These flows are labeled Inputs and Outputs. Other flows are not themselves transformed, and are labeled as Controls or Mechanisms. The design for a part is a control, because it controls how the metal block is transformed into a part. However, the design remains afterward to be used again. The machine tools that shape the part are the mechanisms which actually perform the transformation. They also remain afterwards to make more parts, but the metal block has been consumed, and the finished part leaves the function. Therein lies the distinction between Controls and Mechanisms, which are not transformed vs Inputs and Outputs, which are.

Figure 2.2-1: Single functional diagram box

Functional Diagrams and Data - We can illustrate the connections between functions and flows in Functional Diagrams (Figure 2.2-1), where functions are boxes and flows are arrows. As much supporting data as needed, such as text descriptions, spreadsheets, mathematical models, and simulations, can be attached to given functions and flows. Functions and flows are given names and numbers to match the diagram elements to other data. Complex systems are four-dimensional, existing in three dimensions of space, and one of time. Conventional diagrams are only two-dimensional, so one way to display the functions and flows is in time order from earlier to later. Alternately they can show the linkages between elements regardless of when the functions and flows happen. Effectively these are two-dimensional slices of a four-dimensional system. More advanced displays can show the system in three dimensions and the function activities happening in time, such as a virtual reality simulation, but this kind of display is not yet well developed. We will rely on 2D diagrams for now, and reserve the option for more advanced displays.

Figure 2.2-2: Program phases vs time.

Project Phases

We have identified a sequence of program phases to meet current and future needs using seed factories as a major element. The sequence is based on the scale, environment, and distance of production locations from easier to harder. It also is based on when technology for a phase might be ready, and outputs are needed from a group of locations. The most obvious division of the program into first-level functions is then according to these phases (Figure 2.2-2). Our Seed Factory Project initiates design and prototyping for the larger program, and promotes the program as a whole. We hope that other people outside the project take up and use our designs wherever needed, and contribute their own designs and improvements. The combined effort then leads to meeting the overall program goals. As a project we don't direct other people to implement the larger goals, they are too large in scale and cost. We can only influence people by supplying designs and information, and the reasoning why the goals make sense.

There are seven major phases in our sequence, numbered 0 through 6, and indicated by different colors in the figure. After the first two, the other phases are further divided into sub-phases by location type, indicated by letters from A to F added to the main phase number. Different characteristics of a location will affect the design, so we group them by general similarity into a sub-phase. The phases have staggered start times for two reasons. One is our limited staff and funding means we can't do everything at once. The other is that output products from one phase are used as inputs to build the later ones. Note the time axis (horizontal) is not to scale, it is meant to only show relative time relationships. Note also that phases have no defined end dates. For example, industrial locations in Phase 2B continue to operate as a group for the life of the program. Individual industrial locations may have finite lives, but new ones can be built as needed, so that there are always some locations in operation. Most of our early work will be focused on Phases 0, 1, 2A, and 2B, although we will keep in mind future growth for the later ones.

Figure 2.2-3: Program phases as functional diagram.

Figure 2.2-3 is a high level functional diagram that shows the same phases and sub-phases as the previous figure. Instead of time, it more clearly shows the input and output relationships between the phases. It is not a complete diagram, because it does not show external flows into and out of the program, nor details of the connecting flows. Showing all the flows at once would make the diagram too hard to understand as a whole, so we reserve them for lower-level diagrams which are yet to be drawn. Note that figures in general can be clicked to enlarge.

The remainder of Section 2.2.1.1 will document the analysis of the program and project functions into more detail as we develop it. This work is just starting, so it contains only a partial outline and a start at written content.

Phase 0 - Research and Development

Introduction - Animals in general have always used parts of their bodies as tools to perform the tasks of life. Since the Paleolithic, 2.6 million years ago, the ancestors of modern humans have left evidence of artificial stone tools. They likely also made tools from bones, other hard animal parts, and wood, but these materials are less durable and therefore have not survived from the earliest periods. From the start, our ancestors used tools to make more tools, starting with a hammerstone, striking platform, and core rocks. The core rocks were converted into an assortment of sharp-edged tools by striking them on the platform with the hammerstone. Toolmaking has continued to the present, where we use computer-controlled Machine Tools and robots to make more machine tools and robots. A Seed Factory is a continuation of this process. It uses automated production to evolve from a starter set of equipment to a mature capacity, and then can produce more starter sets. Automation and industrial engineering are well developed fields, but applying them to self-expanding systems that can seed more self-expanding systems is a relatively new idea. We therefore need research and development to take it from the idea stage to ready-to-use designs and equipment.

Phase 0 - Description

[Insert Phase 0 Functional Diagram]

The desired primary output of Phase 0 is then ready-to-use designs and equipment, in the form of documents, computer design files, software, working prototypes, and finished equipment. In addition, the phase may output products made during the testing of prototypes, starter equipment for later phases, and intentional surplus production. All of these can be sold to fund further research and development (R&D). Some of the output can also be used internally to expand R&D capacity. Besides the intended outputs, there will also be waste outputs. These are items not usable as a product or within the phase. They may be used by later phases, or sent elsewhere out of the program for disposal. We want to explicitly track all outputs, including wastes, from the start. By tracking them, we can try to improve our processes so as to decrease wastes, and not create unknown environmental problems.

Inputs are required for Phase 0 in order to perform the desired tasks and produce the desired outputs. R&D is the first program phase. When it begins, there are no automated starter sets yet to begin the replication loop of making more starter sets. So the equipment to perform R&D, and the first starter sets, must be made using existing conventional tools and machines. These are either purchased or self-built. We also require technical data to perform design and test work. There is no added value in repeating R&D already done by others, so part of the technical data is what the current state is for relevant technologies. Inputs and outputs at any level of a system can be categorized in a standard way, as shown in Figure 2.2-4. This reduces repetitive effort, makes sure all input and output types are considered, and makes it easier to sum up and divide flows at various levels.

The R&D work is being started within the Seed Factory Project, whose staff and funding is limited. We hope to partner with other people and organizations to extend the work, and encourage others to start parallel projects of their own. We are starting with one R&D location in the Atlanta metro area, but we expect to grow to other locations for two reasons. One is that interest and skills are not localized to Atlanta. Since the project involves physical equipment and labor, it makes sense set up locations near where people already are, rather than expecting them to travel to one central place. Second, later phases involve different operating environments than the moderate surface climate we are starting from. It will often be easier to test later phase equipment in the actual environment, than to build special test chambers to simulate it.

Phase 0 - Inputs

• System Inputs - These are all the inputs required by the phase which are not yet separately identified. It includes energy, parts and materials, tools and machines, land and facilities, staff, funding, and information. The specific inputs will be identified as we continue our work.

• Technical Data - Performing research and development requires inputs of existing technical data from outside the project. Relevant fields of science and engineering have generated large amounts of useful knowledge. There is every reason to use it, rather than trying to recreate it. These fields continue to make progress, so the data can be divided into two parts. The first is the current state of knowledge as we start the project, and the second is updates to that knowledge as time passes. Mechanisms need to be in place to collect existing and new knowledge as needed. Another input is supporting technical data for the other system inputs. For example, a machine tool may have associated specifications, sales literature, and operating manuals. Sources of technical data include individual staff files and references, existing project files, a project technical library in paper and electronic formats, traditional libraries, online data, and experts outside the project. Once located and acquired, technical data should be organized and made accessible to project members, to avoid wasted effort.

Phase 0 - Outputs

• System Outputs - There are all the outputs the phase generates that are not yet separately identified. It includes surplus items not needed internally or in other project phases, such as energy, parts and materials, tools and machines, land and facilities, staff, funding, and information. It also includes waste outputs not usable elsewhere in this phase, or other project phases.

• R&D Reports - The results of the R&D phase are intended to be widely used. We will therefore produce a variety of report outputs, of which this document is one. Others may include project websites, articles, and books.

• Element Designs - In addition to reports, we intend to supply design data for the machines, software, and other project elements and processes we develop.

• Prototypes - When we have completed internal testing, it is likely that prototype elements will still have a useful life remaining, since the design life will probably be longer than it takes to test the item. We will therefore supply these elements to later project phases for their use, and get feedback to make improvements.

• Starter Elements - The R&D phase will necessarily have some production capacity, in order to build and test prototypes. To help initiate later phase locations, we will produce final versions of starter set elements. How much of this we will do depends on available capacity, and the need to sell other products to support further R&D.

Phase 0 - Controls

Phase 0 - Mechanisms

Phase 0 - Sub-phase Functions

To track and organize the R&D work, we divide the phase into sub-phases, according to the types of locations and later program phases the work is targeted for. Some R&D is general, and applies to any time and place, and some is targeted at the R&D phase itself. So those get assigned sub-phases also. For completeness, we include later phases that we are not doing much work on yet. Sub-phases, and their inputs, outputs, controls, and mechanisms, are given names and sequence numbers to identify them:

Phase 0.0: General Multi-Phase R&D

This first heading covers general R&D that applies to any phase of the program.

Phase 0.1: R&D for R&D Locations

This heading covers research and development for general items to be used at the R&D locations themselves. Examples would be new test methods and equipment used for testing prototypes. Work targeted at specific types of R&D locations are placed under the following sub-headings:

• 0.1A - R&D for Moderate R&D Locations
• 0.1B - R&D for Other Earth R&D Locations
• 0.1C - R&D for Orbital R&D Locations
• 0.1D - R&D for Planetary R&D Locations
• 0.1E - R&D for Interstellar R&D Locations

Phase 0.2: R&D for Moderate Locations

This covers R&D for locations on Earth with a moderate outside environment. Most of the early R&D is targeted at these locations, since they are the easiest and most developed ones, where most people live. They are therefore the first locations to be built.

• 0.2A - R&D for Phase 1: Starter Locations
• 0.2B - R&D for Phase 2A: Distributed Locations
• 0.2C - R&D for Phase 2B: Industrial Locations

Phase 0.3: R&D for Other Earth Locations

• 0.3A - R&D for Phase 3A: Difficult Earth Locations
• 0.3B - R&D for Phase 3B: Extreme Earth Locations

Phase 0.4: R&D for Orbital Locations

• 0.4A - R&D for Phase 4A: Low Orbit Locations
• 0.4B - R&D for Phase 4B: High Orbit Locations
• 0.4C - R&D for Phase 4C: Inner Interplanetary Locations
• 0.4D - R&D for Phase 4D: Main Belt and Trojan Locations
• 0.4E - R&D for Phase 4E: Outer Interplanetary Locations
• 0.4F - R&D for Phase 4F: Scattered, Hills, and Oort Locations

Phase 0.5: R&D for Planetary System Locations

• 0.5A - R&D for Phase 5A: Lunar Surface Locations
• 0.5B - R&D for Phase 5B: Mars Surface Locations
• 0.5C - R&D for Phase 5C: Venus and Mercury Locations
• 0.5D - R&D for Phase 5D: Jupiter System Locations
• 0.5E - R&D for Phase 5E: Outer Gas Giant Locations

Phase 0.6: R&D for Interstellar Locations

• 0.6A - R&D for Phase 6A: Interstellar Space Locations
• 0.6B - R&D for Phase 6B: Exostellar Locations

Phase 1 - Starter Locations and Network

Figure 2.2-4. Top level functions for starter locations.

Starter Locations

Figure 2.2-5. Functions for Provide Production Capacity.

Figure 2.2-6. Output Matrix for Provide Production Capacity.

Production Network

Phase 2 - Distributed and Industrial Locations

Phase 2A - Distributed Locations

Phase 2B - Industrial Locations

Phase 3 - Difficult and Extreme Locations

Phase 3A - Difficult Earth Locations

Phase 3B - Extreme Earth Locations

Phase 4 - Orbital Locations

Phase 4A - Low Orbit Locations

Phase 4B - High Orbit Locations

Phase 4C - Inner Interplanetary Locations

Phase 4D - Main Belt and Trojan Locations

Phase 4E - Outer Interplanetary Locations

Phase 4F - Scattered, Hills, and Oort Locations

Phase 5 - Planetary System Locations

Phase 5A - Lunar Locations

Phase 5B - Mars Locations

Phase 5C - Venus and Mercury Locations

Phase 5D - Jupiter System Locations

Phase 5E - Outer Gas Giant Locations

Phase 6 - Interstellar Locations

Phase 6A - Interstellar Space Locations

Phase 6B - Exostellar Locations

2.2.1.2 - Analyze Performance Requirements

2.2.1.3 - Allocate Requirements

2.2.1.4 - Analyze Design Constraints

2.2.1.5 - Facilities Requirements

2.2.2 - System Level Verification Requirements

Verification is the process of proving your design meets the project objectives. Verification requirements define how that proof will be carried out. For example, "Demonstrate minimum service life by operating for 100 hours and inspect afterwards for parts wear."

2.2.1 - Engineering Specialties Requirements

Section 2.2.1.4 covers outside constraints on the design that come from the physical world and civilization. Examples of the two are available supplies of raw materials and land, and environmental protection rules. Engineering specialties supply requirements from within the project, based on their specialized knowledge and experience.