This specification distinguishes between recipes which are merely present on the vision system and prepared recipes, which have then been activated in such a way that they can be immediately used for processing.

Thus, we have two conceptually distinct operations:

• AddRecipe: Adds a new recipe to the vision system.
• PrepareRecipe: Prepares one of the recipes on the vision system. It is expected that after successful preparation, the recipe can be immediately used by a Start method for processing.

This specification assumes that the client has no knowledge of the internal recipe management by the vision system. The only information provided by the client is the ExternalId and the ProductId.

In many cases, the automation system, represented here by the OPC UA client, will want to work only with the ProductId.

This specification assumes that the client can achieve the objectives of recipe management solely by method calls.

It is therefore not required that the server exposes any recipe information beyond the objects required for the method calls in the Address Space. However, the server may choose to expose recipe information in the form of recipe metadata and references to the actual recipe contents for all recipes of the vision system or a subset thereof.

When the recipe is downloaded to the vision system via the OPC UA server, the underlying assumption is that an internal representation is created in the vision system with an InternalId that is unique in the scope of the vision system/server combination. This InternalId may comprise a hash useful for determining the binary identity of recipes.

This is especially useful in the case of recipes created or edited locally. A recipe may be locally edited. The behavior of the vision system/server combination in the case of local editing of recipes is implementation-defined. Among them (without any claim to completeness):

• The original recipe is kept and an additional recipe is added with new metadata including a new InternalId.
• The original recipe is overwritten with the edited version and the InternalId is changed to indicate the change (especially useful if it includes a hash); note that this may impair traceability in the results.
• The original recipe is overwritten by the edited version and neither the ExternalId nor the InternalId are changed; note that this will impair traceability even more severely.

The remarks on traceablity notwithstanding, the recipe management of the vision system is outside the scope of this specification and the server merely reflects the internal recipe management.

An important case – independent of the various ways of handling versions and IDs described above – is local editing of an active recipe, i.e., a recipe that is currently prepared. In effect, after the local editing, a different recipe is now active than before, so this amounts to the same as preparing a different recipe. Therefore, local editing of an active recipe shall be indicated to clients by a new RecipePreparedEvent.

When a recipe is downloaded to the vision system via the server with an already existing ExternalId and different content from the recipe already present on the system, the behavior of the vision system is again implementation-defined. Among them (without any claim to completeness):

• Keeping both the previous and the new version of the recipe under the same ExternalId with different InternalIds and employing some ambiguity resolution method to decide which recipe to use.
• Overwriting the existing recipe with the new version without changing any Ids, again impairing traceability.

Note that this specification assumes that there may be several recipes on the vision system with the same ExternalId, but different content and different InternalIds, and that it is the responsibility of the vision system to decide which one to use in a given situation.

This specification defines two methods of recipe handling:

• Method-based
• AddressSpace-based

The handling of recipes by calling methods is mandatory as it is expected to be easy to handle byclients. It uses the methods on the RecipeManagementType described in Section 0 to send/retrieve all recipe related information.

The handling of recipes in the Address Space allows for more flexibility on the part of the client as it can do its own browsing and filtering of recipes. On the other hand, it makes higher demands on client and server, and is therefore optional.

If the server offers handling of recipes in the Address Space, it will use the optional Recipes folder of the RecipeManagementType described in Section 7 to expose recipe information.

Information required by the client from the Server includes

• Recipes existing on the vision system (identified by their ExternalIds)
• The assignment between recipes on the vision system and ProductIds
• Recipes currently prepared on the vision system (identified by their ExternalIds)
• Preparedness of a particular recipe (identified by its ExternalId)
• ExternalId of the recipe to a particular ProductId

Note that the OPC UA server is merely a view on the underlying vision system. How a vendor distributes recipe and identification management between the vision system and the server is implementation-defined and outside the scope of this specification.

As long as all data required by the client is available through method calls, it is not actually necessary - although possibly desirable - to expose this information in the OPC UA server Address Space. The OPC UA server will then have to execute a vision system function to retrieve the requested information and return it in an output parameter of the method. For example, the list of recipes existing on the vision system may be requested by a client using a method like GetRecipeListFiltered instead of being read directly from the Address Space.

Exposing meta information on recipes in the Address Space has the consequence that the data is kept in two places, i.e. in the OPC UA server Address Space and in the vision system itself. In this case the implementation has to take care that the data is always updated in both places (for example by the server polling the data).

Exposing recipe information in the Address Space also allows a sophisticated client to carry out requests not covered by pre-defined methods through browsing the data on its own.

Note that sophisticated vision systems may contain a large number of recipes so that exposing the entire recipe metadata information in the Address Space may lead to a quite large Address Space.

Note, also, that this specification does not require the server to expose this information and that the client thus cannot rely on the information being present nor on it being complete as it may cover only a subset of existing recipes, e.g. the list of currently prepared recipes.