5.1 - Personal Production: Requirements

From Wikibooks, open books for an open world
Jump to: navigation, search

System Requirements[edit]

This section lists an initial set of system requirements for the Personal Production project. Identifying them is the first step in the Systems Engineering process described in Sections 4.0 through 4.4. It puts into measurable and specific terms what the finished project should do. The requirements are organized into categories, and numbered for later reference. They are written in terms of the expanded system when it has reached full capacity. The seed factory, which will be the starting point for growth, is determined later in the design process by working backwards from the desired end point.

Following the text of each requirement is some explanation of where it came from and more details about it. There is no "right answer" to setting requirements. They are an attempt to meet the goals and desires of the people who will use the finished design. In this case the particular set of requirements are drawn from a larger program framework for improving quality of life, and maintaining a sustainable and expanding civilization. At the conceptual design stage, the project designers must often act as proxies for the end users. The users may not be identified yet, and don't yet have the information to know what they want out of self-expanding automation. We instead make a best estimate of what they would want, once presented with information about the project. Later on, when users are identified, we can get their direct input to the goals and requirements.

Although we list a number of requirements below, there is no guarantee they are possible or economically feasible. They are a starting point for what we want the final design to do. An updated baseline set of requirements will be an output of the conceptual design stage of the project. During this stage we will make adjustments as needed to what is practical, identify areas that require more development, and record new requirements when we identify them.

1. Objectives[edit]

  • 1.1 Project Goal - The project shall provide a locally owned and operated Personal Production System which supports the needs and desires of the owners and their surrounding community.

This sets the operating regime and basic design function that the system will perform. It is a binary (Yes/No or True/False) type requirement. The requirement is either met or not met. Locally broadly means "within several hours travel time", or approximately a metropolitan area and surroundings. This will be made more explicit later.

  • 1.2 Project Scale - At full capacity, the system shall be capable of delivering 25% by value of the needs and desires of a community of 2640 people.

A target size for full capacity is needed so you can work towards definite designs. The starting size will be much smaller. The community is a larger set than the owner/operators. It includes household members, neighbors, friends, and occasional customers for which things can be made. The particular goal of 2640 people is somewhat arbitrary, but is based on historical examples of settling new communities. The idea is a large enough community would have the skills needed to operate the various production machines, and take care of other necessary tasks. If later design work shows this number is either too small, or larger than necessary, it can be changed. But we need starting values for numerical requirements for the first cycle of design.

  • 1.3 Choice - The specific physical sites used by the project, and their internal organization, function, and operation, shall be chosen by project owners and site residents within the limits of design constraints.

The intent of this requirement is that the owner-operators of the equipment will choose where it is built and how it is operated, rather than these decisions being made from the outside. Completed designs for the factory elements gives them a starting point to select sites, but the final choices will be theirs. Among design constraints are zoning and building codes which limit the types and locations for equipment.

2. Performance[edit]

We want it to operate under a range of actual conditions, so we pick an example location. Later examples will extend to a wider set of locations and therefore have wider design environments. The Atlanta CSA is about 240 km (150 miles) in diameter, which enables reasonable travel time from point to point within the location.

  • 2.2 Growth - The system shall be able to increase its capacity for production, transport, and habitation by at least 5% per year after initial start-up.

To make the design desirable for the owners, it should be able to more than just maintain itself, and have a generous margin for growth. The extra capacity could be used to increase the community size, start up new locations, or make products for sale. Five percent is a minimum design goal, and higher growth rates are desirable. Initial start-up is between whenever the starter set begins functioning and 10% of full capacity. In this early phase, there will be fewer types of machines available and skills within the community, so we allow for a lower growth rate during this period. The growth being measured is through internal production. Additional people joining the project, or contributing assets to the project can grow it faster.

  • 2.3 Improved Technology - The system shall increase its levels of self-production, cyclic flows, and autonomy in a progressive manner.

We do not expect the founding community and initial equipment to have the same abilities as at full capacity. This requirement sets a gradual increase in technical performance as the factory grows. We will set a goal of 25% for now as the full capacity target for self-production, recycling, and automation as a reasonable goal for a first-generation design.

  • 2.3.1 Local Resources - The system shall be able to supply 25% of community needs and desires from local resources, as measured by economic value.

This puts more detail on 1.2 Project Scale above by supplying materials and energy from local sources. Local includes the project sites themselves when feasible, otherwise from within the Atlanta area. To meet the parent requirement (2.3) of progressive improvement, we set targets of 6, 12, and 18% of needs met at 3, 10, and 30% of full capacity. So with a community of 80 people, and perhaps 20 owner/operators, we want to meet 6% of their needs. The improvement is tied to geometric increases in capacity, because easier products would be made first, and copies of machines made to increase capacity, which doesn't increase the range of products. Being able to supply a need defines a design capacity. Whether people actually use the equipment to full capacity depends on personal circumstances and choices.

  • 2.3.2 Self Production - The system shall be able to produce 25% of the total economic value for the community internally, with the remainder from outside work and savings.

The previous requirement covers resource supplies. This one covers economic value of the outputs, including work by the owners as operators. Again, we think 25% is a reasonable level at full capacity, with the same partial goals as the previous requirement. Participation levels will vary across the community, from casual to dedicated, so 25% is an average. The Personal Production example isn't intended to replace most conventional jobs and other income sources, but as a supplement to them. With some level of automation, the time needed to do both should be possible. The starter set and start-up level of growth (first 10% of capacity) may only support hobby-level production, while at full capacity it would support more substantial contributions, at the level of a second income. We think a gradual shift to self-production is more feasible than trying to do so all at once. All-at-once examples are colonies or communes, where everyone is 100% devoted to the new efforts. These have often failed for various reasons, so we do not attempt that approach.

  • 2.3.3 Cyclic Flows - The system shall be able to recycle and reprocess 25% by mass of local waste flows from community production, transport, and habitation.

This requirement comes from several sources. Closed cycle flows are more sustainable in the long term. They have lower input costs because you do not need to pay for as many new inputs. They also have lower disposal costs than linear (use once and dispose of) flows produce. We expect that the production equipment's ability to process materials and level of automation will make the recycling economically inexpensive. The 25% goal is again at full capacity.

  • 2.3.4 Automation - The system shall be able to reduce human labor requirements by 25% relative to the US average.

Automation is desirable from a quality of life standpoint - more output for less work. The owner/operators do not have to worry about automation putting themselves out of jobs, since they own the production. Less work and economic security are key parts of making the Personal Production system something people will want. We think 25% labor reduction by automation is a reasonable level for a first generation project. It assumes some level of production integration, so that transfers between production steps can be automated, as well as the individual machines being automated. Just because a task can be automated doesn't mean it has to be automated. For example, an automated garden can produce food efficiently, but someone may choose manual gardening for pleasure or for the exercise.

  • 2.3.5 Autonomy - The system shall be capable of controlling at least 25% of production, operations, and maintenance functions locally.

This flows partly from the desire for owner choice and ability to run things under control of the people who live with the results. Having the capability does not require it be used. Participants or specialists who are not in the local area can operate parts of the system by remote control as an option.

  • 2.3.6 Complexity - The starter set shall include not more than 8 types of custom production elements, not counting attachments.

One of the growth paths for the project is diversifying to new types of equipment and processes from the hundreds available. However we want to start with a smaller set to lower initial cost and design complexity. On the other hand we do not want to start with too little. For example, we could in theory start with zero production elements and rebuild technology starting from rocks, sticks and fire made by hand, but that is not very practical. A compromise is to start with about one piece of custom equipment per major production function, so that a reasonably complete production chain is possible within the system. Additional attachments, bits, consumable supplies, tooling, and small shop tools are needed to outfit any kind of working production system, but are not counted in this total. We refer only to custom equipment designed for the project. Any standard items that people can buy or build are also not counted.

  • 2.4 Improved Quality of Life - The system shall be able to support an equivalent GDP/person of 25% above the US average.

The goal of meeting needs and desires does not say at what level of quality for items like food, shelter, and utilities. Naturally we would like a high level of quality, and we think with automation and self-production this can be reached. The GDP equivalence sets a target well above the US average, and is in terms of what it would cost to reproduce the lifestyle. The base GDP is $18.23 trillion in 2016 in current dollars with a population of 323.26 million, and thus a base value of $56,394/person. Cash income would not be increased proportionally, because many products are delivered directly to the community. In theory, if the production system delivered 25% of needs and desires with no impact on existing work and lifestyle, the equivalent GDP would go up 33% from the base. Since some work will be needed by the owner/operators, we don't expect the new activity to be purely additive, but somewhat decrease conventional work. So the goal is a 25% increase. As with other requirements, this is a goal at full capacity, with a gradual increase.

  • 2.5 Data - The system shall share project experience and data with the local community and beyond.

As a first of it's kind project, we would like others to build on the knowledge gained and hopefully feed back their own experience. Including it as a system requirement ensures we will include processes in the design for collecting and then sharing the data. We recognize that personal data will need to be carefully protected. This requirement is about technical features like solar collector power output.

  • 2.6 Resources - The system shall be able to output at least 2.0 times internal needs for materials and energy.

This comes from a desire for a highly productive design that comfortably produces above it's own maintenance and support needs. It also supports a higher quality of life either by directly supplying items to the owners, growth of the factory, or surplus production for sale. This is measured at full capacity, after building production facilities and equipment. It is related to the concept of "energy return on energy invested" (EROEI) for energy sources, but extended to also cover material resources.

3. Time[edit]

  • 3.1 Completion Time - [Not Applicable]

A project schedule or completion date is often used as a time-based requirement. In this set of requirements we cannot set a time to reach full capacity because we do no know how fast people will join the project or what research and development is needed yet. For now we mark 3.1 Completion Time as "Not Applicable", at the system level. At more detailed levels of the project, we may derive time and schedule requirements, and reserve this requirement number (3.1) for that purpose.

  • 3.2 Operating Life - The system will be designed for an indefinite life with maintenance, repair, and replacement of parts.

This project is intended as a permanent source to supply community needs. Therefore it will not have a finite life or wear out date. Since the individual elements cannot be designed to last forever, a consequence of this requirement is the need for maintenance and repair tasks.

4. Cost[edit]

Cost requirements put a bound on how much effort goes into designing and building a system. They are a judgement about the worth of the project relative to all the other things people can put their time and assets towards, and the benefits the project would bring. Total costs are divided into Development Cost - the one-time costs for technology, prototypes, and design; and Location Cost - the repeating costs for each added unit or copy you build. We use Mid-2016 US dollars for our cost requirements, adjusted for inflation.

  • 4.1 Total Development Cost - Development cost for the project shall be less than $40 million for a community of 300 people, net of sales.

The manufacturing industries, which our project fits within, typically do not invest a lot in research and development. Since we want to apply modern automation to these areas, we assume a relatively high development cost. In the absence of better cost estimates, the specific number is twice US average capital per person. This assumes most equipment is not completely new design at the 300 person scale. Developing a project cost estimate is part of conceptual design, so this value will be updated. A higher development cost is justified if many personal production systems are eventually built based on the design. The Personal Production prototypes, and early expansion phases are able to make items for sale. Any items sold during the development period are credited against the cost, so $40 million would be the maximum net outlay.

  • 4.2 Location Cost - The unit location cost after development shall be less than $66,600 per person supported.

This covers the repeating cost for production capacity per average community member supported per the other requirements. This is a relatively low number because automation and self-production is intended to make things at lower cost. The $66,600 is intended to cover the outside raw materials, parts, and labor which still need to be purchased. It is an average number per person at full capacity, and may be higher to start with. The total tangible assets of the US are $86.1 trillion as of mid-2016, or $266,400 per person. Since the project goal is to meet 25% of people's needs and desires, we divide the tangible assets by 4. This number is also preliminary, and will be updated as cost estimates are developed during conceptual design.

5. Technical Risk[edit]

  • 5.1 Risk Allowances - The system design shall include allowances for performance and design uncertainties of less than 37.5% when complete.

No engineering design is perfectly understood, or built and operated exactly as intended. Therefore there will always be some uncertainty in performance, wearout rates, and other parameters. A technical risk allowance is a design margin above the required performance to account for this uncertainty. In other words, we design for more than we need to make sure we at least meet a required level. Risk allowance is measured at the point the design is finished and building the equipment starts. Once the system is built and operating, you will find out the actual performance. The uncertainties are set high in this example because it is a first-of-its-kind project. Uncertainties will be even higher at the start of design. The intent is to lower them during development by methods like simulation, component tests, and prototypes. Note that technical performance risk is distinct from failures and safety hazards.

6. Safety[edit]

  • 6.1 Location Risk - The system shall have a community life and property risk of less than the US 2016 average.

Safe operation is a desirable feature, and often mandated by law, so we include it as a requirement. This is to be met at full capacity, and applies to the project-owned land and equipment, and the community of people it directly supports. Manufacturing and transport typically have risks associated with them, but we think we can keep their levels no higher than average by automation (which removes people from work hazards) and design for safety (prevent risks at the design stage).

  • 6.2 Population Risk - The system shall reduce natural and human-made risks to the nearby population by 5%, including external risks created by the system.

The previous requirement was for risks of the project to the owners and the community they directly support. This one is for risks to others outside the project. We would like to have a positive impact on the nearby community. We define nearby as zones 10 km wide around the project sites, with at least 50% of the risk reduction applied in the nearest zone, 25% in the next zone, and so on. The number of people we reduce the risks for is equal to the project community size. So at full capacity in the Atlanta area we are making a positive contribution to safety for a small part of the total population.

7. Sustainability[edit]

  • 7.1 Biosphere Security - The system shall preserve 178 (species x number of sites) outside their existing natural ranges, either stored or living.

In addition to present safety, we want to contribute to long term sustainability of the biosphere. The number of species, and number of sites they are preserved at, is scaled to the size of the project, so we use a relatively small number here. By preserving species outside their existing natural range, recovery from hazards to the original population, like climate shift or human development is possible. Example preservation methods include greenhouses, seed banks, or replanting in recently shifted climate zones.

  • 7.2 Survivability - The system shall provide 0.0025% compensation for civilization level critical risks.

Besides the biosphere, we want to contribute to the long term survival of human civilization. A project this size can only be expected to make a small contribution, therefore the requirement value is small. Example methods would be helping address resource depletion by recycling, or atmospheric carbon accumulation by renewable energy sources. We acknowledge this is a challenging requirement, but we think it is worth at least trying to meet it. At a minimum we want to understand our impact on civilization as a whole. By setting a requirement, we then have to measure how well we are reaching it.

8. Openness[edit]

  • 8.1 Open Design - Technology and design methods developed within the project shall be open for others to use. Specific instances of a design and produced items may be proprietary.

Our larger intent is not just to support one local community, but to demonstrate self-expanding production systems are possible and enable others to use them. We need to balance sharing the underlying technology with rewards for the people who do the work. So we allow people to keep specific hardware designs private if they choose, and own physical items they build. The general technology, methods, and prototype designs developed by the project are shared openly, and people can optionally contribute their own improvements and modifications.

Measures of Effectiveness[edit]

During the design process, attempts to meet the various requirements often affect more than one at a time. For example, higher performance and reliability often come at the expense of higher cost. To optimize a design when this happens, we use measures derived from and strongly related to the requirements. How well each requirement is being met is converted by formula to a numerical score. The scores are combined, and the better design is then the one with the highest total score. In this way very different requirement types can be accounted for and compared across different design options. For this project we will use a 100 point scale and assign a certain number of points (their weight) to each measure according to their relative importance. The score by formula is found for each criterion, and the total score is the sum of weight x percent score for all the measures. Note that some requirements are fixed, like the number of people the project supports. They don't get variable measures, but rather the design is adjusted to meet them in full.

The measures as a whole are a mathematical model of what we think is better in a design. Like the requirements in the previous section, there is no "right answer", since they are based on human goals and choices. What the measures do is allow different people, or one person working on different parts of the project, to reach a consistent solution based on the same assumptions. In the table below we list our selected scoring items and formulas. The individual items only total to 78% because not all measures are included for the Personal Production example. They will be included in the later design examples, and we want to be able to easily compare across projects. The scoring formulas also have relatively low goals compared to later projects, since Personal Production is a first-generation design. The total sum of the scores is adjusted by a ratio to bring the result for this example to a nominal 100 point value. It would not be adjusted when used to compare to other examples and projects.

Table 5.1-1 - Initial Measures of Effectiveness:

Measure Weight (points) Scoring Formula (percent) Goals
2.2 Growth (rate/yr) 5.0 (equivalent % annual GDP growth of all sites - 2.5%) x 10 Goal = 5%. Internal production valued as if sold at market rates
2.3 Improved Technology (local resources) 1.0  % of local resources from program locations Goal = 25%. Measure by kg (mass) or Joules (energy)
2.3 Improved Technology (self production) 1.0  % of finished products from program locations Goal = 25% by economic value
2.3 Improved Technology (cyclic flow) 1.0  % of location mass flows reused Goal = 25%. Includes local use but not production for growth or sale
2.3 Improved Technology (automation) 1.0  % reduction human labor hours Goal = 25% lower relative to current technology
2.3 Improved Technology (autonomy) 1.0  % required labor and control supplied locally Goal = 25% of necessary functions can be supplied
2.4 Quality of Life (GDP) 5.0 (equivalent GDP - $20,000)/2000 Goal = $70,500/capita. Includes value of internal production and labor
2.6 Resources (surplus) 5.0 ln(material & energy output/internal use)/ln(2) x 25% Goal = 2.0 over program life cycle. Clip at -100%
4.1 Total development cost 14.0 (avg unit cost/total development cost) x 50% Goal = 2 x location cost = $133,200/person
4.2 New Location Cost 14.0 [(ln(0.25xUS capital per person/location cost))/ln(2) x 25%] + 25% Goal = $66,600/capita
5.1 Technical Risk Allowance (%) 5.0 (50% - technical uncertainty allowance) x 2 Goal = 37.5% technical allowance
6.1 New Location Risk (relative) 7.5 [ln(0.25 x general casualty risk/location risk)/ln(2) x 25%] + 75% Goal = 100% relative risk. Includes life and property risks.
6.2 Population Risk (relative) 7.5 (% reduction to general population risk) x 5 Goal = reduce 5% by natural & program causes, higher risk not allowed.
7.1 Biosphere Security (species-locations) 5.0 [(log(species maintained outside natural range x sites)) - 1] x 20% Goal = 178 in vivo or stored, humans are a species
7.2 Survivability (relative) 5.0 (% compensation for critical risks) x 10,000 Goal = 0.0025%. includes all civilization level risks
Total 78 Sum partial scores x weight from each line above x 400/78 Goal = 100% after 400/78 adjustment

Notes to table:

The formulas are intended to produce scores of zero when the measure is at an unacceptably low level:

  • 2.2 - The formula subtracts 2.5% from growth rate to set zero score at "no better than average growth in the economy"
  • 2.4 - The formula subtracts $20,000 from the GDP/person value to set a minimum low income base.

At the other end of the scale, the formulas should produce scores of 100% for self-expanding systems that do everything we want at the highest levels. Since Personal Production is a first generation design, we only target scores at around 25% of the ultimate values, indicating there will be much room for improvement afterwards.