The previous two examples, Personal and Industrial Factories, have considered designs at a single location. For this example we consider a network of distributed production nodes at different locations, which we call a MakerNet. The network can expand in two ways. Each node can self-expand as in the previous examples. In addition, nodes can collaborate on building new nodes. As in all our examples, the nodes and network as a whole use part of their output for expansion, and the rest for end products for users.
We will start with a general description of the concept, and in later sections develop more detail on how such a production network is designed and built.
A MakerNet consists of a set of nodes and the transport systems that connect them. A Node is a location that contains some set of design or production capabilities. It might be as simple as a single machine or independent designer, or as complex as a fully expanded factory. Nodes transfer physical items, energy, and data to each other according to agreed protocols, using one or more transport systems. They also interact with outside entities by already existing conventional methods. The data portion of transfers includes design information, production orders, and payments. Ownership of nodes may be independent or by shared entities (associations, corporations, etc.) A Cluster is a set of nodes that are close enough to effectively work together. As examples, they may be co-located in an industrial park, or within a single metropolitan area. The effective working distance will tend to vary inversely with the mass transferred between them and positively with the value of the transfers. Thus design nodes may work together from anywhere in the world, because design data is high value and zero mass. Gravel, on the other hand, is high mass and low value, so moving it between nodes will only be effective a short distance. Members of a cluster may optionally set preferences or priorities for transfers between themselves. The Network is the set of all nodes and clusters that share the same transfer protocols, plus the internal and external transport systems that do the deliveries. This allows them to communicate data, distribute work, and collaborate on making products, including new nodes to expand the network. Nodes may freely join or leave the network, although agreed work-in-progress and transfers should be completed before leaving.
Node and Transport TypesEdit
The nodes within a given network all share the same transfer protocols, but they can have widely varying contents and functions. Since a given node can evolve and expand over time and add new functions, it cannot be permanently placed in a discrete category. However, we can use descriptive names, like a metalworking or chemical processing node, to help understand how the network operates. Such descriptive names for nodes are not necessary when we treat the design and protocols in the abstract. We can also describe node types with some loosely defined categories. A "specialty" node only performs one or a few related tasks, while a "general purpose" node can perform a wide variety of them. Examples of specialty nodes include design nodes, mining nodes, and power nodes. General purpose nodes that output a lot of end-products can be described as "seed", "expanded", or "industrial" factories. Ones with less output can be described as "workshops". "Commercial" nodes would mostly make products for sale, while "private" ones would make items for personal or internal use.
The transport systems that connect nodes can also be described by categories. Internal systems are owned by network members, for example delivery trucks. External systems are owned by outside entities, such as an Internet Service Provider or a public road. Transfers can also be logically distinguished as between network members or between members and outside locations. However, the same transport systems can be used for both types of destinations, with perhaps the exception of not using the network protocols for outside deliveries. Functionally the transport systems are described by the type of entity being delivered. Our reference architecture for self-expanding systems currently includes Bulk Cargo, Discrete Cargo, Humans, Energy, Fluids and Gases, and Data. Both nodes and transfer systems can be described by how they operate. For example, they can be described as manual, remotely operated, or automated.
An Operations Concept describes how the network would operate once built. At present this is only a starting point for further analysis and design. Our network operations concept follows a communicate, agree, and execute sequence. This is similar to how traditional business has operated with advertising, quotations, contracts, production, delivery, and payments. The difference is a fully developed network can use the protocols, production nodes, and transport systems to fully automate the process.
In concept, node and transport systems advertise their capabilities and costs in a standardized format via a network protocol. This could be done on a distributed peer-to-peer network or as data supplied by a website, but the specific design can be left for later. The capabilities information would include equipment capacities, production location, cost, schedule, and other relevant data. Another node, or an outside customer, who need something made or supplied, can search the network for suitable capabilities. They can then send requests for information or requests for quotes for custom work, or place an order if it is a standard item. The receiving node then accepts the order, places it on their production schedule, and communicates progress from time to time. In an early development stage some of the steps may be manual, while in a fully developed network this may be entirely automated.
Design files for a product would contain enough information to build it. This includes required materials, quantities, and processes, shapes of the parts, assembly instructions, etc. The format for design files would also standardized, so that they can be matched to node capabilities. More detailed steps for the network operation starts with a user, either from outside or part of the network, who wants a product made. We will use as an example a dining table for home use. The user reviews available designs on the network, or if they want something custom, the capabilities of design nodes. Once they have chosen a final design, their local ordering software can compare the product's requirements to the available advertised capabilities for production and transport. The software can generate a rank-ordered list of nodes or clusters which can deliver the completed item. The customer can review these candidates, contact them for additional information, or simply go ahead and submit the order. The orders would include reference to the design files that specify what is to be built, delivery instructions, and proof of available payment. The node that gets the initial order, in turn sends out orders to suppliers as needed. For example, a woodworking node that completes the dining table may send out orders for lumber and hardware. For complex items, a single original order may generate a chain of additional orders through the network and from outside suppliers. A large commercial node may be able to complete the entire product, while small individual nodes may need to split the work between them. One node might supply lumber of the correct sizes, another uses a table saw and other woodworking tools to shape the parts, a third does the finishing and assembly, and a fourth delivers the finished product. The order generation and delivery of the design files may be entirely automated once the customer authorizes it.
In order to pay for the various production tasks, the person making the order places sufficient funds in escrow on an electronic payment network such as Bitcoin. Transaction records are public in this type of network, thus the node operators can see the funds have been placed in escrow. The escrow guarantees the funds are available, but they are not delivered until the work is complete. When a node completes their work, and delivers their items to the next node, or to the end customer, the escrow is notified to release the funds to pay them. This step may also optionally be manual or automated. Because transaction records are public, nodes can prove they completed the work and were paid. If order data are also a matter of public record, the combination of order and completion history can serve as a reputation measure for nodes. This can be used by future customers to help select nodes for new work. A reputation system is an optional feature for this kind of distributed production, but it may be useful.
Network Creation and GrowthEdit
We do not expect such a network could be designed and built all at once. Instead, we can start from existing non-networked businesses and entities who agree to work together. They do not have to devote all of their work to the network, but can allow it to be added incrementally. The first step beyond just associating with each other and manually sharing data is for one or more design nodes to develop the transfer protocols, and then supporting software to handle purely electronic transfers such as design data and payments. At this level the actual work to satisfy single orders can still be by whatever conventional means they already used. The next step is creating product designs with sufficient information to distribute tasks across multiple nodes, and optimized for production within the growing network. Orders then can start to be issued in parallel from the originator or as a chain where one node generates sub-tasks for other nodes. Along with the new designs, nodes can begin to automate their internal operations and deliveries to increase efficiency and lower costs.
The network is intended to operate and grow on an ad-hoc basis in a distributed fashion, rather than a centralized top-down design. However, network members can collaborate on improved designs and protocol updates. New nodes can establish themselves by posting their capabilities to the network, and can change or remove that data at any time. They may start out with purely manual operations, and only download network software to communicate capabilities and orders. Some of the products individuals can order are intended to be new production elements, which allows them to expand and automate their capabilities. The thus the network can self-expand by adding new nodes, new product designs, and internal production of more elements. As the network grows, it can become more automated, and produce a wider range of needed items internally. A fully built network could supply the majority of it's own inputs and outputs.
It will take work to design, build, and operate a Distributed Production Network. There have to be enough advantages in having such a network to justify its creation. At this point in developing the concept we cannot prove those advantages exist. We can, however, list potential benefits, and then investigate them further as the concept evolves:
- Individuals can join the network with minimal capabilities at first, but gain the benefits of the rest of the network immediately. It may lower the barrier to entry compared to conventional business start ups.
- The extent and rate of self-expansion can produce high rates of capital growth.
- To the extent the ordering, payment, and production tasks are automated, it would have low overhead and high productivity.
- Routing of individual tasks to the nearest/fastest/cheapest nodes for each customer may be more efficient than centralized production at a single location.
- Filling orders for a wide range of customers may optimize and stabilize production schedules, and automatic reassignment of tasks to other nodes may better handle delays or breakdowns.
- Enhanced privacy is possible if the orders and payments are only identified by account numbers, and the final delivery is a closed container. The shipper only needs to know the destination, but not what is being shipped or the price.
- Ownership and leasing strategies may be automated, so that at any time people are working for themselves (with automated equipment). This may have tax advantages.
Having described the general concept, we now turn to how such a system can be designed. This section is very preliminary for now. This book as a whole is about self-expanding automation. We presented a common Reference Architecture in section 3.4, and a systems engineering-based design process in section 4.0. We adopt these as starting points for this particular example of a distributed network. Like other self-expanding systems, a distributed network is complex, so we plan the growth in phases, and divide the whole project into smaller elements to simplify the design task. In this case, the starting point is existing business processes and equipment, as they are now. The early phases add network communication and payment software, and conventional equipment to support new production tasks. Once network members are ordering parts and products from each other, they can start to design custom hardware and setting up production nodes in later phases.
Because it is distributed, this example will place more emphasis on the transport functions and elements which connect locations. Historically factories and offices were centralized because it was the less expensive solution. Modern communication and transportation equipment have lowered those costs, so more distributed solutions are feasible now. Other factors like reduced commuting time and energy use for shipping can come into play. It is still useful for design and optimization purposes, however, to treat a set of production equipment as an integrated entity, despite the pieces being physically separated and under different ownership. Even if the elements are widely distributed, it makes sense for operating efficiency to design them to work together and use standardized interfaces and protocols. There are existing examples of such distributed systems, such as the Internet itself, and the traffic control network for airplanes. There will still be advantages to grouping things together physically, but we treat it as a design choice based on circumstances, rather than a default assumption. Other factors like availability of start-up funding and staff may drive a more distributed solution.