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.