Refers to the NRP-CAS.

A recipe is a pattern of activity which helps users of the NRP-CAS to plan work and manage complex processes. Currently, Sensorica has implemented two types of Recipes in its NRP system: Workflow recipes and Manufacturing recipes.

We see peer production as Agents swarming economic activity (innovation, production, dissemination / distribution etc. ), crowdsourcing (assembling) required Resources. We implement that as Recipes, which are chains of Processes with temporal dependencies. A Process is an input / output pattern, Resources go in, deliverables go out to feed the next Process.

Recipes are associated with Resource types. Not all Resource types have a recipe. Recipes are essentially scripts, series of processes that are required to create or modify a resource. They are suitable for repetitive activities, simple, or complex, like manufacturing. They are less suitable for more chaotic, or emergent, or less predictable types of activities.

See more on Recipes on the github repository for the NRP-CAS.

Manufacturing recipe

Since manufacturing is a very structured and deterministic activity it is very suitable for recipes. The Manufacturing recipe is easier to understand, because it is more concrete. Every product, or everything that is produced in a repetitive manner can have a recipe (or a script). It contains all the processes required to produce the thing: the tasks (with their structure and associated time requirements), lists of consumable materials and equipment required, spaces used, etc. If there is a need to make the thing, anyone can plan the work by using the Recipe, by simply exploding the Recipe into a series of actions or processes that are then distributed to network affiliates.

Sensorica is also designing recipes to be applied to services. See the 3D course project example.

Support for modular products

Background

See Bob's message in Sensorica-infrastructure group

Theory

It seems that versatility and modularity are important features of open source hardware artifacts. The idea is to design the NRP-CAS to handle that. This requires an analysis of commonality and variation. We need to identify independent and dependent variables.

A feature belongs to one and only one Product. A Product is an Economic Resource Type that is offered for sale. A Feature can have many options. Each Option is linked to one and only one Component. (A Component is an Economic Resource Type that is assembled into a Product.)

By interposing options between products and components, one component can be an option in more than one Product.

A feature is an input to a Process Type which produces its related product as an output.

So for example in the context of a Recipe:

PRODUCT would be an output of
- a Process Type maybe called "Assemble PRODUCT" which would have an input of
  - a Feature called "subPRODUCT-1" which would have options of
    - subPRODUCT-1.1
    - subPRODUCT-1.2
    - subPRODUCT-1.3
    - subPRODUCT-1.4

Each of the types of subPRODUCT-1 would have their own recipes, including process types and possibly their own features and options So if you had a configuration calling for PRODUCT with subPRODUCT-1.1, a schedule would be generated for the Assemble PRODUCT process with the subPRODUCT-1.1 and any other inputs of that assembly process, and then the process for creating the subPRODUCT-1.1 with any of its inputs, including any configured options, and on and on recursively until the system ran out of recipes or ran into purchased or inventoried components.

Limitations of this design:

This design is for assemble-to-order products, not manufacture-to-order (where the manufacturing process is configured, instead of or in addition to the optional features) or engineer-to-order (where the product and process design are configured).
This design does not allow for a selected option to require a different assembly process for the end product. In other words, the PRODUCT in this design would have the same assembly process type regardless of what type of subPRODUCT-1.x was selected. A different design would be required to allow for different assembly processes, but then if the PRODUCT had more than one feature with options that required different assembly processes, you could have a combinatorial explosion of assembly processes.
Configuration rules and constraints must be added to the design. Unlike option-specific assembly processes, they should be easy to add later as needed.

Praxis

See Value network recipe design principles
For a Process Type, you can add either inputs, which are directly specified, or features, which are special inputs that have selectable options.
So we'll add a feature to the Assemble Mosquito sensor process called Transducer, and also select Transducer as the category for options. (If you don't select a category, when you go to select options, you will see all resource types in the system.)
So now we have created the feature, and will go on to select options.
We select all of the transducer types as options. We could have omitted some.
And here is the result on the Change Recipe page. As you can see, the joint-type transducer has a recipe, which appears below the option. The first picture above was snapped from the View Recipe page, by limiting the depth to 2 levels.

Features and Options will be used in customer orders, similar to the way you might have configured a computer online. The customer will see a feature called Transducer, and the list of options to select from. Once they select which transducer type they want, the order will be scheduled for production.

Workflow recipe

The Workflow recipe is a planning tool that allows any OVN affiliate to create a series of processes in the NRP-CAS and distribute tasks.

The Workflow recipe is somewhat similar to the manufacturing recipe. It was first introduced by Bob and Lynn for Guerrilla Translation to represent the path of a text to be transported, going through different stages of translation. This process is linear and represents something getting gradually improved or built, or refined, step-by-step, in a linear fashion.

Sensorica is applying it to R&D, or product development. As mentioned before, recipes are scripts and apply to patterns of activity. Even if R&D seems to be more chaotic than manufacturing, it still follows general patterns. For example, all R&D is about moving something through stages, from

idea -to-> design -to-> prototype -to-> product

We know that an R&D process is somewhat chaotic, with forks, merges, and cycles between design, prototyping and manufacturing. Unfortunately the workflow recipe cannot represent these things.

If we look more closely, there are other activities associated with this pattern. For example, the ideation and the design processes are usually informed by a need, therefore a "market study" needs to be done in parallel. If this new product development process happens within an OVN, one needs to make sure that resources will flow towards the project, in terms of skills, materials, money (some form of currency), etc. Therefore, we can also graft an outreach process to the initial R&D pattern.

Nevertheless, until we develop better tools, we can try to use the Workflow recipe as a tool to formalize a methodology. Sensorica has implemented a dual workflow recipe system (see more below) to deal with product development, one that deals with technical work called the R&D workflow and the other one which deals with creating the conditions for the project to develop. These two workflows, structured by two Recipes, maintain a set of relationships between them as seen on this diagram.

Use of Workflow recipes in Sensorica's NRP-CAS

Sensorica has implemented a dual workflow recipe system (see more below) to deal with product development, one that deals with technical work called the R&D workflow and the other one which deals with creating the conditions for the project to develop. These two workflows, structured by two Recipes, maintain a set of relationships between them as seen on this diagram.

Create Workflow Recipe

Workflow recipes, as any recipe, are attached to a Resource Type. You can either create or modify a recipe for an existing Resource type, or create a new resource type and a recipe attached to it. To create a new Resource type, go to the Resource types page, and click on the Create new Resource Type button. Within Sensorica, we consider that R&D processes produce an R&D report document. Therefore, the output of an R&D process should be at least an R&D report. Other resources can be created during the process, but they are considered secondary. A generic resource type called R&D report was created.

Think about the Workflow recipe as a formal methodology for what you want to do. When you build a recipe, you need to create a series of processes. The first process creates a changeable resource, i.e. a resource that will be transformed throughout the workflow. Chose Changeable in the settings of the first process. Chose Change in the settings of all the other processes, meaning that all these processes change the resource. Chose time estimation and Quantity should be 1 (it needs a quantity).

Workflow recipe for R&D

NOTE: Collaboration between Fernando Dorneles, Lynn, and Tibi to create a Workflow recipes for Sensorica's R&D. Open Template for new Projects & the Folder

Two Workflow recipes were created to structure R&D activities.

The first one is associated with a resource type called R&D report, and it represents technical processes that bring the product idea through different stages, from idea to product. Open the recipe for R&D. It is assumed that the central resource produced by an R&D process is an R&D report, referring to ideas, designs, prototypes, and to descriptions and characteristics of prototypes. During the R&D process other resources might be created, such as protocols and methods, manufacturing recipes, etc.
The second one is associated with a resource called Conditions for project, and represents a bundle of processes that establish the conditions for a project to develop. Open recipe for conditions.

These two parallel recipes maintain a set of relations, as described by this diagram created by Fernando Dorneles and Tibi. The workflow recipe for R&D was improved with input from Steve Bosserman, see his Solutions development paper on p2pFoundation. See also Steve's article Peel the onion.

How to use a Workflow recipe for a new R&D project

There are two ways to use an existing Workflow recipe (methodology for product development) for a new project. Using the recipe means use the Recipe tool in NRP-CAS to generate a work schedule or a plan for the entire project. You will be able to modify this plan.

From the Demand page

Press Plan work using recipe button
Chose the Project for which you want to use this recipe - NOTE that this presupposes that your new project is already registered in the system, see HELP on how to create a new project.
Click Get Recipes
Click on Conditions for project ( Document ideas, Any R&D, Sensorica ) Workflow Recipe, chose a due date and give it a name that contains the name of your project. You can change the due date and the name later.
Do the same for the R&D report.

From the Resource Type

Open the R&D workflow recipe

Work to be done on Recipes

Allow more than one recipe per resource. See issue on Github

Work done by IoP

See Open Know-How Specifications

Recipe

Contents