4.0 - Design Process

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



General Process[edit]

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


  • Systems Engineering - We start by treating the whole production capacity, and any tightly coupled elements it interacts with, as a single system with functional elements, a boundary to its surroundings, and flows of resources across the boundary and between the elements. The complete system is successively broken down into smaller logical elements (functions) and the flows that connect them. System goals and performance are passed down to the smaller elements in such a way that the pieces add up to the desired total. 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.
  • Applying Design Concepts and Ideas - In the process of setting project goals, dividing the system into functional elements and the flows that connect them, and identifying alternate designs to meet the goals, we incorporate the design concepts from section 3.0 where appropriate. If they do not provide a distinct advantage over conventional designs for a particular project, they do not need to be included. To these concepts we add new design methods and tools adapted to self-expanding automated factories.
  • Element Design - When the various elements 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 others. 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 various elements are then linked into a complete design (integration) and considered as a whole to verify they meet the total project goals. There are numerous books that cover the various fields of engineering, so we will not reproduce all their details here. Instead we will discuss it in general terms in sections 4.1 to 4.4, and provide links to more detailed sources.


A design team, however skilled, is not capable of fully optimizing a complex system as a single linear process through 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 added cycles of refinement are not expected to gain as much improvement as the effort for another cycle would take, the design work then stops, and a project transitions to production, construction, and operations.

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 and hobby use, 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 machines to make products for each other, or help build new network nodes. New sites within a regional location, and distinct locations, start with partial equipment sets. They grow with the assistance of existing network nodes. 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 home and hobby scale, 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 at multiple sites. Commercial and industrial scales mean the outputs are beyond the personal needs of the operators, and now 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 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 seed factory methods to tap these unused resources, which are currently too difficult or expensive to access. In particular, increased energy allows more recycling and sustainability. Distance and difficult conditions means we emphasize remote operations, and setting up complete seed factories. 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 larger program. The outputs of each example are then used as inputs to the next example, in an unbroken growth process. The different examples and a linked sequence require different factory outputs and therefore different designs. 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 Personal 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 [TBD Location] for reference.

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 cycle is first used to reach a useful level of productive capacity. At that point a "version 1.0" set of equipment can be built based on the current state of the design. The design cycle is then either continued to add more capacity, develop upgrades, or modify the designs for new locations, or halted temporarily and started up again at a later time. Reasons for additional design include feedback from real operating experience, and new technology developed outside the project. The development of initial and later versions is similar to the incremental development of software, and in fact a large part of a networked and automated factory design will actually be software.


Systems Engineering[edit]

As noted briefly above, Systems Engineering 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 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. An self-expanding production system, with seed and mature states, and all the growth steps in between, is complex both in the design for any one time, and the fact the design changes continuously over time. Therefore the Systems Engineering method is suitable for this kind of project. Systems engineering connects the work of more specialized fields like mechanical, chemical, and electrical engineering, but it does not replace them. The detailed specialty work still needs to be done. What systems engineering does is coordinate the process and the pieces of the design, so that the end result in total does what you intended.

Figure 4.0-1. General Systems Engineering Steps.

In the Systems Engineering method, (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. The steps in the method include:


  • Identify Needs and MOE - The overall performance, cost, and other design goals for the system are called System Requirements. Requirements originate from an end user who has a need to be filled, or a design organization that observes a need and sets out to fill it. They specify in measurable terms what the system is intended to do. Measures of Effectiveness 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.
  • 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.
  • Allocate Requirements - The system requirements are broken down into component requirements, similar to how the functional elements are divided. This includes performance, operations, and maintenance for the complete functioning system. The component requirements are assigned as appropriate to the functional elements. This breakdown is called Analysis. The individual parts then each have their own assigned subset of the requirements to meet. Effectively they form a smaller and simpler subsystem within the total project. The intent is when you sum up the design and operation of the entire hierarchy of subsystems, they will then meet the original top-level goals.
  • Model System and Alternate Approaches - Having assigned the requirements to the various levels of functional elements, the designers then consider alternate ways to meet the requirements for each part. This includes identifying the options, quantifying them in terms of numerical models, drawings, and other design information, and incorporating them into a complete model of the system.
  • Optimize and Trade-Off Alternatives - The design parameters are adjusted and alternatives compared within the system model so as to select the best options. If the right measures were selected in the first step, "best" means "highest combined score across all the measures".
  • Synthesize and Document Configuration Baseline - The designs for the various parts are then put together, which is called Synthesis to make sure the design as an integrated whole meets the original system requirements. Finally the resulting design is documented in a version baseline.


For a complex system this process does not happen all at once, usually multiple tries and refinements are needed to get the best complete design. Tracking all the pieces and how they relate lets you make piecemeal changes and see how they affect the overall result. Figure 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 describe the steps in more detail in the following sections, but they can only give an introduction to systems engineering methods. It is a well-developed engineering specialty, and we refer the reader to the many books and articles that cover it in more detail. 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[edit]

A general goal for the Personal Production example, might be "produce products and outputs for home and hobby use of the equipment owners". 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 like that in 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 options often affect several at once. For example, increased safety in a given option may also increase cost. To choose among design options that affect multiple requirements, we convert the various requirements to a common scale and combine them to measure how well the design meets the full set of needs. A common measuring scale lets us choose the "best" option by adding up component scores for each requirement and picking the option with the highest total. The components that go into this scale are called Measures of Effectiveness, where each score measures how effective a design option is at meeting a particular requirement goal.


Requirements Definition[edit]


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 design for. As systems have gotten larger and more complex, affecting more people, and end users have gotten more discerning in what they want, more requirement categories have become important. These include 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 in 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. Growth from a starter set has many possible directions. Working backwards narrows the choices to the ones that lead to the desired end point.

Like other parts of the system, the starting set of requirements are not permanently fixed. They can be updated in the course of development. However, the starting set should be as well determined as possible. Later changes will require re-working the design, which increases cost, so as a goal requirements changes should as few as possible.


Measures of Effectiveness[edit]


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 measures to account for this. Like requirements, they are derived from end user desires as to what would be "better" when comparing one design over another. The measures are usually strongly related to the requirements set. Since different features typically have different units of measurement, they 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. Another reason is if the requirement is a basic feature which must be met, or the design would not meet it's intended purpose. In these cases, any design option must fully meet the fixed requirements, and the ones that are variable are allowed to adjust as needed.

The 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 their income or political philosophy. Therefore independent studies are needed 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 no new design is good enough to satisfy what the end user wants, or is sufficiently better than what exists already to choose it. A current example 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 design 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. Often the cause of a low score is not enough performance improvement relative to cost, but other measures can give such a result.

A scoring system can also be used to determine in advance how much improvement would be needed to justify a new design. That improvement then becomes a goal for research and development. Executing the project would then wait until the research reaches those goals. 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 seed factories, 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[edit]

A number of concepts and ideas were identified in sections 3.0 to 3.4. We want an organized process to apply these concepts into our design. We do this via an Applications Analysis which takes each concept or idea and considers where among the systems engineering steps and design data a given concept will be used. A possible outcome is a particular idea may not be used at all on a given project. The analysis records where the concepts are applied, and the reasoning behind those choices. The actual application of a concept is via imposed requirements, functional elements, design checklists or design features that are incorporated into project. This will be done in more detail for the later examples. We provide a preliminary version 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[edit]

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

  • Closure Ratios (CR) - This is the percentage of the factory itself, end products, or both combined, which it can make internally, in terms of parts count, mass, value, or other key factor. The remainder 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 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 need to be >1 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 a factory can produce, P/t measures how fast it can do so. Higher rates should lead to better economics and faster growth of the factory. Production measures are first derived from design data, then measured on actual 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 last group are growth rates and ratios 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:

  • 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


Motivations and Economics[edit]

Motivations and economics ideas were listed 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. If enough reasons are identified to motivate people and groups, they are then presented in reports and presentations to them. Taking action requires knowing an action exists and is possible.

Economics - Economic reasons are known to be powerful motivators to take action, use available inputs, and provide goods and services. Since people have physical needs and personal desires, they are motivated to obtain 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.

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 and for sale. The goal is to maximize satisfaction by optimizing this division of outputs. People's needs and desires are variable, including for one 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 become no longer viable and should be decommissioned.


Technical Concepts[edit]

Technical concepts related to seed factories 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 technique across 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 incorporated 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.
  • Generalized 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 CO2 waste problem, towards alternatives like electric transport. Waste dumps and scrap materials often represent lower grad 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 bad side effects.
  • Cyclic Flows - We have already mentioned recycling by exploiting waste streams as low-grade 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.


New Ideas[edit]

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

  • Resource Accounting - Is the method of applying 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 seed factory projects in particular. These would have to be custom-designed, or adapted from existing software as part of the overall design process. A Process Compiler would take design files that include items like dimensions, materials, and assembly instructions, and convert 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. Additional software will be needed to operate individual machines, and to network them so that commands and status can be delivered. Augmented reality and telepresence were not possible in 1980, 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 display 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 Steps - 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 it ignored the details of final products and made the factory design very complicated. In our current work we start with a much simpler seed factory that evolves toward a mature capacity targeted at particular products. It evolves by adding different machines than were in the starter set and scaling in size, in addition to making exact copies of the original machines. The evolution can be broken into less complicated steps, like adding one new machine, 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 to an original starter set. Some items can't be made by a given set, so outside supplies of parts and materials are added, but this should decrease as the growth proceeds.
  • Universal Factory - This 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[edit]

We described the 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 developments.