Engineering the Future
A Program to Upgrade Civilization Using Systems Design Methods
Contact:
Dani Eder
The Seed Factory Project,
6485 Rivertown Rd, Fairburn, GA 30213
email: danielravennest@gmail.com
Section 0 - Program Overview
0.0 - Overview Introduction
editModern civilization is in a sub-optimal state. There are catastrophic and existential risks from causes like resource depletion, environmental change, war, and natural disasters. Although rapid technical progress is being made, many people are poor, or at risk due to things like job uncertainty, health problems, or accidents. Political and economic systems have evolved to satisfy some needs, but incentives are slanted against the average person, and the systems were not designed for the modern age. Rather, they grew over time and contain legacy elements that are now obsolete. We believe civilization is due for an upgrade where people can be safe, secure, healthy, and happy. Hope is itself a powerful force. Many people today are discouraged because they think we don't have a future, or that things will never get better. Merely showing that a better future is possible will give people hope and motivation to work towards it.
We propose using engineering methods to design solutions to the above-mentioned problems. Engineering methods have already solved large problems like supplying clean water and sanitation to two-thirds of the world. So there is good reason to believe it can address other large scale problems. Since civilization is now very complex, we propose applying Systems Engineering methods to the task of designing the upgrades. Systems engineering is a field that focuses on how to design and manage complex systems over their life cycles, making it a particularly appropriate tool. It is interdisciplinary, using knowledge from multiple fields to meet specified goals. It is not the only tool we can use, but experience has shown it to be useful for tasks such as this.
Because of the scale of modern civilization, and the scope of the problems, any solutions will take time to implement, and the participation of many people. This author, or even an "Upgrade Program" with a large engineering and design team, cannot hope to implement the solutions by ourselves. At best, we can identify the solutions, design systems and technologies, and demonstrate and implement them on a local scale. We hope that others will find the solutions useful, and go on to use them elsewhere. This document serves as a combination engineering notebook and report for our work to date. Section headings follow a standard systems engineering topical format for recording and organizing the data. It resides on a Wikimedia system to allow others besides the current author to comment and contribute, and to make our work accessible to anyone with an interest. To keep page sizes reasonable, they are divided into sub-pages when they grow too large. Consistent section numbers and links join the pages into a single document. In the early stages there will be gaps in the numbers for sections that have not been started yet.
0.1 - Systems Thinking
editSo how do we approach trying to solve the problems of civilization? It involves "systems thinking", which first requires understanding what a system is.
0.1.1 - What is a System?
For engineers, a System is a collection of entities which work together, defined by a boundary which separates it from the surroundings outside the system (Figure 0.1). We select the boundary for the purpose of better understanding and analysis. It is a mental construct, rather than physical boundary like a fence. For our purpose, the system is civilization as a whole, and the surroundings are the rest of the universe. Flows of various kinds can cross the system boundary as inputs and outputs. For example, sunlight enters from outside, and waste heat leaves. Flows can also connect internal entities within a system. Engineering is based on the sciences, and creation or destruction ex nihilo (out of nothing) would violate the Conservation Laws of physics. Conserved in this sense means a quantity that stays the same. So flows cannot appear from nothing or vanish into nothing, though they may be transformed into other types. "Conservation of flows" is a powerful idea. It means simple financial-type accounting applies to the activities of a system and all its parts. Flows may divide or combine, but the sums before and after are the same. The change in internal contents of an entity or complete system is equal to the sum of incoming flows, minus the sum of outgoing flows, and so on.
0.1.2 - System Subdivision
We can define system boundaries wherever it useful to do so. An important concept is to treat the entities within a system as their own, smaller, systems. We call such systems within a system "subsystems", and this can be done at multiple levels. Large, complex systems, like civilization as a whole, or even individual products like a passenger airplane, are too complex to comprehend and design all at once. Dividing them into smaller and smaller subsystems eventually brings you to a point where you can design the pieces. The pieces are then fitted together into larger wholes, which is called "system integration". During integration you consider how the pieces connect to each other, and can mostly ignore the internal details of each piece. At each level you integrate a limited number of pieces, which keeps the complexity of the task manageable. Integration at multiple levels makes it possible to combine the hundreds of thousands of parts in an airplane, or the millions or billions in all of civilization, into workable complete systems.
Engineering and design processes for a large project are themselves complex, so they are also divided into smaller and simpler pieces, as displayed in the structure of this document. Systems engineering methods can be and have been applied to itself by treating the process as a system with inputs (i.e. design goals) and outputs (i.e. fabrication drawings). So it can be used recursively to optimize and upgrade its own methods. The design and engineering fields are also too large and complex for individuals to fully understand. This is solved by using specialists in particular fields, who apply their understanding to subsystems or steps in the design process. Groups of coordinated people can then design complex systems, which would otherwise not be possible to do.
0.1.3 - System Dimensions
System boundaries have physical dimensions, but also exist in time, which is considered a dimension in physics. So systems have a beginning and an end, and a Life Cycle in between. The life cycle is also divided into pieces, typically starting with concept exploration (the first stage of design), and ending with final disposition of system elements. Disposition happens when the usefulness of the elements ends, or when they are transferred to a new system. Subsystems and flows likewise have time elements. Humans barely can comprehend four dimensions of space-time, and tools for three-dimensional display of system elements and boundaries are still being developed. So conventionally we display system elements and flows in parts, as two-dimensional diagrams and one-dimensional lists. Diagrams can show physical or logical connections between elements. They can show slices of the system at a particular time, or connections among parts across the whole life of the system. Diagrams can also be oriented in the time dimension, as in operational sequences or schedules. Lists and tables can show the parts of a system as a hierarchy or sequence, with whatever amount of information is desired attached to each part. This document, for example, is a one-dimensional sequence of sections. Diagrams visually show connections better than tables and lists, but are limited in how much detail can be presented at a time. So information is best conveyed using both diagrams and lists.
When trying to understand a system, it is important to remember that the elements we display in these various ways are not disconnected from each other, but rather pieces of a larger whole. They can influence each other even if not explicitly linked together. The limits of page or monitor size, and human ability to absorb large amounts of detail at once, are what lead us to display the information in pieces. Computers are not so limited in handling large masses of detail. So we can build computer models of an entire complicated system to better understand how it works.
0.2 - Civilization as a System
editWhat is Civilization then? Historically there were multiple civilizations in different places. Their connections were weak because of the difficulty of travel and communication. So they are better understood as separate entities. Today worldwide transport and communications networks have created a single unified civilization. It is best understood as a whole, although it has many distinct parts.
We take an engineering view in order to define the system boundary: Civilization is that part of the Universe purposefully modified to meet the needs and desires of the people who live within it. It includes the people themselves, the knowledge and skills they have accumulated, all of their cultural artifacts, and modified parts of the natural world which are not themselves artifacts. An example of the latter is abandoned farmland which has been allowed to re-forest. It is composed of natural elements like soil and trees, but is no longer in the original condition due to past grading and tilling, species mix, and other changes. The Earth's atmosphere and parts of the oceans are now also part of civilization under this definition. This is not because of previous uncontrolled fishing and inadvertent greenhouse gas emission, but rather more recent policies to bring these activities under control. We are now purposefully managing future changes in these areas, making them part of civilization.
The remainder of the Universe outside this boundary is called the System Environment. The environment for each system will be different, but in this case includes almost everything beyond the atmosphere, the unmodified depths of the oceans, and land below the surface layer touched by human activity. A few areas in space, such as Geostationary orbit are now part of civilization as we define it, because of the large number of satellites there, and their defined orbital slots and transmitting frequencies, making this orbit purposefully modified by occupation. Mere travel through an area, as the Mars surface rovers do in their exploration, does not make that area a part of civilization, as we are not purposefully modifying the Martian surface. The rovers themselves, as human artifacts, are part of our civilization. Orbital debris, which consists of non-functional satellites and fragments thereof, are human artifacts. Once they enter the atmosphere and burn up, they have returned to the natural environment. Similarly, shipwrecks are artifacts so long as they are distinguishable from the unmodified ocean bottom. We are carefully defining our system boundary to understand the scope of what we are designing for, and so we don't miss items, activities and flows that are contained within, or cross the system boundary.
People, in our engineering view of things, are not an undifferentiated mass any more than all vehicles on the road are the same. People have different needs and desires, and have variable properties like age, language, and skills. In attempting to find solutions to the problems of civilization it would be an error to ignore these differences. An example of this error is when Communist states lumped people into a mass proletariat, who were all assumed to have the same goals. Information, ideas, knowledge, and skills are a part of civilization to the extent they are transmittable between people and over time. Natural skills such as athletes and musicians have, as distinct from their added training, are inherent to them and can't be taught to others. They are considered part of the variable nature of people, like their height or eye color.
Civilization already exists, and we do not expect to build a new one any time soon that is so isolated as to be a separate civilization. Civilization can't be disposed of like a smaller system, because we are part of it. So the starting and end points of a system's life cycle don't apply. Civilization is also already evolving, and will continue to do so if we make no attempt at improvements. So the scope of our work is to identify and design desirable upgrades to the state civilization would otherwise evolve to, to demonstrate the upgrades to extent we can, and promote their adoption by others.
0.3 - Projects and Phases
editAs mentioned in section 0.1.2, it is useful to divide large engineering programs into smaller and simpler parts that can be worked on individually. Improvements to the industrial base that supports civilization can address problems of limited resources, environmental change, poverty, and economic uncertainty. These improvements have two aspects: the technical methods used to make things, and how the benefits of better production are distributed. For example, it does not do much good to develop highly automated production if it leaves masses of people unemployed and unable to afford the products being made. A great deal of effort is already going into technology for recycling, renewable energy, and automation, but not so much into how to distribute the results. Seed Factories are a way to handle the distribution question. These are automated production systems that can grow from a small starter set to any desired size, much like a tree grows from a seedling. The starter set is affordable for a community or a network of individuals, and they then benefit directly from the mature production capacity. This type of factory includes automation, recycling, and renewable energy technologies. But it adds the new feature of design for self-growth. It uses stored designs and instructions to make more equipment for itself, as well as finished products for people to use. Seed factories are a new idea, so we have established a Seed Factory Project to work on them, as part of the larger program to solve civilization's problems. So far it is the only distinct project, but we expect others to develop over time.
Expandable production systems can be used in many places and for many purposes. The details of their design would differ for each, just like we have many designs for internal combustion engine vehicles (motorcyles, passenger cars, large trucks, etc.). A mature factory can also produce new starter sets intended for new locations, with different operating environments and different products being made. So the project to develop them can be organized into logical phases, starting with the easiest locations and simplest designs, then progressing to the more difficult places and complicated designs. We have identified the following location-based phases:
- Phase 0: Program Research and Development
- Phase 1: Starter Locations and Network
- Phase 2: Moderate Locations
- Phase 3: Other Earth Locations
- Phase 4: Orbital Locations
- Phase 5: Planetary System Locations
- Phase 6: Interstellar Locations
See the article "To Mars and Beyond", Part 1 and Part 2 for a more detailed description of the phases.
Section 1 - Program Organization
1.0 - Organization Introduction
editPrograms begin with one person's ideas. Once many people are involved, the work should be organized so the results are reached efficiently and correctly. Even at the single person stage it helps to be organized, because human memory is fallible, and you can't hold all the parts of a complex design in mind at once. This section explains how the program is being organized. Later sections cover technical details of the designs we develop. At present (Sep 2016) it is an open-source effort with no outside funding or hired staff, so we cannot direct anyone to do anything in particular. What we can do is invite people to participate, and use collaborative tools like this WikiMedia document as part of our process. It is used to inform ourselves how we think best to go about doing things, and what work has been done and the results obtained. We expect our plans, processes, and organization to evolve over time.
1.3 - Program Planning
editOne of the systems engineering methods is to organize tasks in a logical way. Tasks often are worked in parallel, or in a cyclical and iterative way, rather than a simple linear sequence. Iteration is repeating a design cycle where you develop more detail or better optimize each time. Specialists are not always available when needed, and people don't come up with ideas and solutions on a set schedule. Organizing tasks helps plan upcoming work so that people and resources are available at the right time. A task structure also helps record work done so far, so that other people can find it when needed. A Work Breakdown Structure (WBS) is an example of how tasks can be organized. This document uses a standard systems engineering WBS to organize the sections.
1.3.0 - Program Structure
edit
All programs have a start and an end, and a life cycle in between. While civilization itself does not have an end point (we hope), our program would end when the problems we identify are solved, civilization's systems are upgraded, and the outdated parts retired. Figure 1.3-1 shows the stages of an idealized program life cycle, from concept to decommissioning. In the diagram, one stage leads to the next in strict sequence. In practice, the stages overlap and there are feedback loops, such as experience from test, operations, maintenance leading back to updates to the design stages. When displayed with time going from left to right on a schedule chart, the stages look more like Figure 1.3-2, with staggered starting points, but overlapping in time.
Technology development, both in civilization as a whole, and particular technologies within the program, is expected to be a continuing process rather than a one-time event. Therefore the first level of structure below the whole program is a series of program phases implemented when sufficient levels of technology are reached. Each phase includes upgrades and expansions to existing locations, and establishing new locations enabled by the improved technology. We cannot predict in detail what new technologies will be developed, or how well they will work. Thus the later phases are more in terms of goals and direction to follow than specific design details. Prior to the first permanent locations, we have a Technology Development Phase (Phase 0), and currently identify three Construction Phases (I, II, and III), marked by improved technology and performance. At present the phases target program criteria total scores of 30, 40, and 50 points, although this may change as the work progresses.
The next level of structure is the set of locations to be built or upgraded within each program phase. The specific locations will not be identified until much farther into detailed design. At present we have identified five general ranges of locations, and are working towards defining them in more detail:
- Temperate Earth - Defined by environment parameters within which 90% of people currently live, with 5% at each extreme outside these limits.
- Difficult Earth - Where one or more environment parameters are 10% or more beyond their temperate ranges.
- Extreme Earth - Where one or more environment parameters are from 20% beyond their temperate ranges, up to the limits of practicality.
- Near Earth Space - These are locations less than 10% beyond escape energy of the Earth-Moon system relative to the Earth's surface.
- Distant Space - These are locations beyond Near Earth Space in energy terms.
The level below locations, which is Level 4 in the structure counting the program as Level 1, is the set of functions that occur at each location, and the systems that implement those functions. The primary functions of production, habitation, and transport are expected to recur in multiple locations. The system design to implement these functions is likely to be the same or similar across multiple locations, so it makes sense to approach their design from the general standpoint at first, and then adapt to specific locations as variations to the basic designs. More detailed analysis from the functional standpoint is just starting. There are a large number of candidate systems and designs identified to satisfy the functions and higher level program goals. We will note them in this paper, but we have not established if they are needed in the program at all yet, nor when or with what specific features.
Section 2 - Systems Engineering
2.0 - Systems Engineering Introduction
editSections 2 and later cover the technical, as opposed to organizational tasks, for the program. Since Systems Engineering is our chosen method to coordinate the work, it is covered in this section. Later sections will cover other tasks like design and manufacturing.
2.1 - Initial Program Definition
editEvery engineering program must have a starting point. For our Upgrade Program we use the previous sections as our input, with the understanding it is incomplete and will be modified as the work progresses.
2.1.1 - Program Objectives and Requirements
editThe premise and objectives above are not yet specific enough to design to, so an early step in the design cycle is to identify requirements (measurable features) which we want our end result to have. We also identify a starting concept for how civilization would meet this end result.
2.1.1.1 - Needs Assessment
Characterize the state of civilization and its problems using system requirements categories. This will flow into program requirements as needs that are not currently being satisfied. Requirements are specific measurable features for a program to meet. Designs are evaluated as to how well they meet these requirements, and the best ones chosen. There are already economic systems and programs in place to address some of the identified problems. If they are adequate to the task, we can note them with "no changes required", and include them as-is in a baseline program. If they are not sufficient or can be improved, then we can make a recommendation for others to implement, or start a project ourselves, as needed.
2.1.1.2 Program Goals and Objectives
- Goals
A well defined program should have a set of goals to work towards, against which current and new projects can be compared, and progress measured. We identified a set of such goals that are assumed to be desirable for civilization. They are human goals, rather than space mission goals as such. The expectation is a space component will be part of the final program concept, but it is not specified as an input. Our initial goals include:
- Improve Life on Earth - by developing better technology for living sustainably from local resources.
- Understand the Earth Better - by observing our home planet, its environment in space, and other planets and environments.
- Reduce Hazards from Space - by identifying what they are, followed by developing methods to deal with them.
- Increase Biosphere Security - by adapting to more difficult environments, including future changes in the Earth itself.
- Expand Accessible Resources - by improved access to currently difficult Earth and space locations.
- Long Term Survival - by dispersal to multiple locations and acquisition of critical new resources.
- Increased Choice and Freedom - by opening unoccupied locations to habitation.
- Increased Opportunity - by access to unclaimed resources and more efficient technology.
Additional benefits from reaching these goals include:
- Low Cost Access to Space - by removing barriers that keep current costs high.
- Spin Off Technology - since technology developed for one purpose inevitably finds uses in other areas.
- Optimism for the Future - by demonstrating we are not limited to a finite, closed, and degrading world.
- Objectives
Having identified problems and unsatisfied needs, we now want to set down specific objectives for our design methods to accomplish. These objectives are ambitious, but by thinking about civilization as an integrated system, we may discover solutions where looking at individual problems may not:
- Identify principles and goals for human civilization by which we can distinguish good from bad design solutions. For example, the Happiness Principle posits that the goal of civilization is to maximize total happiness. The challenge is to define, measure, and implement such a principle.
- Design methods to reduce or eliminate Catastrophic or Existential risks to human civilization.
- Design methods to reduce or eliminate individual and social problems and risks. These include poverty, job uncertainty, lack of skills, health problems, and accidents.
- Design political and economic systems which are fair to everyone, and adapted to the modern age and the future.
- Demonstrate technical feasibility and economics of proposed concepts. Design an overall program path to implement them.
- Research, design, and prototype needed technical improvements where possible. Encourage others to do so if they are beyond our ability.
2.1.1.3 - Program Requirements
- 1. Objectives
- 1.1 Program Goal - The program shall expand human civilization to a series of new locations with increasingly difficult environments and distance.
- 1.2 Program Scale - Expansion shall be demonstrated by permanently supporting at least 95,000 humans total among new Earth locations and at least 2,000 humans per new space location.
- 1.3 Choice - Specific locations and their internal organization, function, and operation shall be chosen by program participants and location residents within the limits of design constraints.
- 2. Performance
- 2.1 Number of Locations - The design shall maximize the number of new locations, where new is defined by at least a 10% increase in an environment parameter or distance measured in time or energy terms.
- 2.2 Growth - Each location shall increase the capacity for production, habitation, and transport in a progressive manner.
- 2.3 Improved Technology - Locations shall increase the levels of self-production, cyclic flows, and autonomy in a progressive manner.
- 2.4 Improved Quality of Life - Completed locations shall provide an improved physical and social quality of life relative to the upper 10% of Earth civilization.
- 2.5 Data - The program shall collect and disseminate [TBD] data about the Earth's environment, surrounding space, and objects therein.
- 2.6 Resources - The program shall output a life cycle surplus of at least 100% of internal material and energy resource needs.
- 3. Schedule
- 3.1 Completion Time - The expansion to a new location shall be completed before expected progress in technology indicates a re-design is required.
- 4. Cost
- 4.1 Total Development Cost - The total program development cost for new technology and hardware designs shall be less than 50 times the unit cost on Earth, and 5 times the unit cost in space of the hardware.
- 4.2 New Location Cost - The peak net project cost for a new location shall be less than 50% of the expected long term net output.
- 4.3 Earth Launch Cost - The program shall progressively lower the Earth launch cost component of total system cost, with a goal of $0.08/kg of total system mass.
- 5. Technical Risk
- 5.1 Risk Allowances - Program designs shall include allowances for uncertainties and unknowns in knowledge, performance, failure rates, and other technical parameters. New designs with higher risk can be included in program plans, but a process shall be included to resolve the risk, and an alternate design with lower risk maintained until resolved.
- 6. Safety
- 6.1 New Location Risk - New locations shall progressively lower internal risks to life and property, with a goal of significantly lower risk than the general population.
- 6.2 Population Risk - The program shall significantly reduce natural and human-made risks to the general population, including external risks created by the program.
- 7. Sustainability
- 7.1 Biosphere Security - The program shall increase biosphere security by establishing alternate biospheres and long term storage of biological materials.
- 7.2 Survivability - The program shall design for the long term survival of life and humanity from changes to the Earth which will render it uninhabitable and depletion of critical resources.
- 8. Openness
- 8.1 Open Design - Technology and design methods developed within the program shall be open for others to use. Specific instances of a design and produced items may be proprietary.
- 8.2 Access - Development of a new location shall not prevent reasonable access for transit or to unused resources.
2.1.1.4 - Initial Program Concepts
Our starting concepts include:
- Maximize total happiness by ensuring long-term survival and sustainability of civilization. An extinct civilization has no happiness, and one that runs out of resources will be below maximal happiness levels. Material scarcity means not everyone gets what they want, or even enough to live. Work out of necessity, rather than preference, forces people to do things they would rather not. Scarcity and necessary work should be minimized to maximize happiness.
- Survival and access to resources are increased by distributing civilization across the Solar System. Accessible material resources are much greater, and abundant energy from the Sun is sufficient for full recycling of materials, making them sustainable. The Sun's energy sources, and the heat sink of the cosmic background, will endure for billions of years.
- Automated self-bootstrapping, upgrading, and reproducing networks can address scarcity and the necessity for work. They can supply the elements for production, transport, habitation, and services, to establish civilization wherever needed or desired. Fully autonomous replication is hard to design, so start with people and inputs from existing civilization.
- For engineering purposes, we can divide civilization into primary segments such as Production, Transport, Habitation, and Services. These are divided into systems, such as Resource Extraction and Energy Supply, and further divided into system elements, like Facilities, Hardware, Software, People, and Processes.
- Our designs are not static end points. A key feature is evolution over time by growth, expansion, upgrades, replication, and configuration changes. Increments of growth and evolution are identified by program phases, which may be related to each other logically by series, partly overlapping, or parallel links, and physically by new locations and new configurations for existing locations.
- Overall Program Concept
We expand the range of human civilization to a series of more difficult environments, building production capacity, habitation, and transport for each location. Once established, we then start building the next location. The first locations are temperate Earth ones, where improved technologies are demonstrated in areas like remote operations, automation, resource extraction, and recycling. Temperate locations are where most people live today, so the technologies have the widest immediate application there. It is also easier to start developing them without contending with difficult environments, and with local access to people and supplies.
As the technology improves, successive locations are built in more difficult Earth locations such as the oceans, deserts, ice caps, or deep underground, and then eventually moving out into progressively more distant space locations. Production capacity from previous locations is used to help build starter hardware for later ones. The successive locations provide places to live and work for increasing numbers of people, and interact with the rest of human civilization as any community does. The intent is to use the improved technologies to provide a better quality of life for the residents, and a surplus to send to the rest of the world. Newly started locations, like any construction site, will take a while to reach that level. Expanding to new locations provides new places for people to live, which increases choice and allows freedom to try new social and business arrangements. It also increases access to new unclaimed resources. This increases opportunities and the resource base on which human civilization depends.
A particular idea we consider important is the “Seed Factory”. This is a starter set of equipment for a new location, which can make parts for more equipment for itself, as well as finished products for other uses. As the seed expands to a full production capacity, it makes an increasing range of products and needs a smaller percentage outside parts and supplies. This is a more powerful idea than a replicating system which only copies itself:
- A seed factory does not have to be able to make full copies of itself. It can use a percentage of outside supplies. This makes it smaller and simpler to design, and less expensive to start with.
- A seed factory can not only grow by building copies of existing equipment, but by building larger versions of the equipment, and by building new types of equipment that widen the range of possible outputs.
The design of a seed factory should make optimal use of human labor and technologies like automation, robotics, and remote control. In temperate locations this is for cost and efficiency reasons. In difficult environments it enables early construction when the location is not yet set up for human residents. Besides the seed idea, we also consider as important technologies the local extraction of resources, recycling, and high efficiency transport. These reduce long term dependency on, and costs of, a location from outside support.
2.1.1.6 - Measures of Effectiveness
- Program Criteria and Requirements
Category | Weight (points) | Specific Criteria |
---|---|---|
1. Objectives | 7.5 | Program scale in population |
2. Performance | 27.5 | Number of locations, growth rate, improved technology, quality of life, resources |
3. Schedule | 0.0 | None (included in growth rate) |
4. Cost | 35.0 | Development cost, new location cost, Earth launch cost |
5. Technical Risk | 5.0 | Allowance for technical uncertainty |
6. Safety | 15.0 | Location risk, general population risk |
7. Sustainability | 10.0 | Biosphere security, survivability |
Total | 100.0 | Sum of above scores |
The program is intended to benefit civilization as a whole, but we cannot ask every person what their design preferences are. It is both impractical to ask 7 billion people what they want, and most of them don't know enough about the subject to make an informed decision. Therefore we act as a proxy for them and make our best estimate of what they would tell us if we could overcome the impracticalities. The preferences are embodied in a set of evaluation criteria, which are derived from the program goals and other sources. Each criterion is scored on a relative scale, nominally 0 to 100%. The criteria are weighted against each other in importance by assigning points out of a nominal total of 100. The score for each criterion times its weight is then summed across all the criteria to produce a total score. Selecting the best design is then a matter of choosing the one with the highest score. The scale used in this scoring system is arbitrary. What is important are the relative values among different features of a program. The formulas implicitly define exchange ratios, such as how much extra cost are you willing to accept for better performance, or how much quality of life is worth relative to risk. This scoring system also simplifies evaluating a design with features that have different units of measurement by converting them all to a common numerical scale. A summary of the program level criteria are listed in Table 1, and a more detailed table and how they were arrived at can be found in STEM Section 5.1
The program goals (noted in section 3 above) are too general to design to, so they are converted to more specific and measurable statements. These are called "Requirements", from the fact that the design is required to meet each statement. The initial values for the requirements were set from our best understanding at the start of the study. As the conceptual design progresses, and what is feasible and optimal emerges, they will be updated to a more specific and final set of requirements. These will then be allocated to lower level program elements for design and implementation. The initial set of requirements are listed here, and how they were arrived at can be found on page 3 of STEM Section 5.1.
2.3 - System Design Synthesis
edit2.3.1 - System Architecture / Early Design
edit2.3.1.5 - System Architecture
- Reference Architecture for Self-Expanding Systems
- Consider customer, business/organizational, and technical contexts in presenting the architecture.
- The reference abstracts multiple instances of applications, and shows their relationship.
- Contains mission, vision, and strategy details, customer needs, and opportunities to use technology.
- Provides guidance for multiple users and organizations for how to develop instances.
- Flow from technology R&D into new elements & output products, using distribution network for designs & hardware.
2.3.3 - Models and Simulations
editSystems and subsystems interact with each other in complicated ways. One way to understand the interactions is by building a mathematical model of the component activities and flows between them. This allows you to estimate the effects of proposed changes or new projects, and to optimize the systems as a whole. Mathematical software, like spreadsheets and simulators, are typically used for modeling, because of the large number of calculations required.
2.4 - System Evaluation and Decision
edit2.4.2 - Specialty Engineering
edit2.4.2.2 - Reliability
- Root Causes
Treating a symptom rather than the root cause of a problem does not really solve it. Engineers have developed methods to trace problem causes, and identify which ones are the most useful to fix. Generally you don't have the resources to fix everything, and some things cannot be changed. So you have to select the things that will make the most difference to fix. An important example of a symptom is war among nation-states and sub-national organizations. Most people don't want a war, because of the risks and damage they cause. But underlying causes like placing oneself or one's group above the welfare of others, and allowing psychopaths to be in positions of power, can lead to war. It is those roots that must be fixed, not just winning a particular battle.
Sections 3-12 - Design, Test, and Other Tasks (TBD)