T12: Templates

Step 1 — Build one properly first#

You already have Filler 1, with a chain, calculations, and events. Before templating, confirm it is genuinely right: units set, formats set, divisions guarded, availability between 0 and 100.

Step 2 — Author the template#

Switch to the Template view. This is a separate space from the Model view, and template content belongs here.

Create a template folder called Equipment Templates, and inside it a template metric called Filler.

Add the measures, mirroring what Filler 1 has:

Measures inherit template-ness from their parent, so adding measures to a template metric produces template measures without further ceremony.

Step 3 — Make the tags templatable#

A template with a hard-coded tag is not reusable. Each instance needs its own tag.

Use a model attribute token in the tag:

FL00[ModelAttribute("Filler Number")].BottleCount

The attribute resolves per instance, so instance 1 reads FL001.BottleCount and instance 2 reads FL002.BottleCount.

Do the same for the energy tag: 110-JQ-00[ModelAttribute("Energy Channel")].PV, which resolves to 110-JQ-001.PV and 110-JQ-003.PV for the two fillers the simulator provides.

Template = shape. Attributes = specifics. That pairing is the whole idea.

Step 4 — Create the destination folders and set attributes#

Back in the Model view, under Production, create three folders:

Production
+-- Filler A
+-- Filler B
+-- Filler C

Set model attributes on each:

Filler C reuses Filler A's tags — the simulator only provides two fillers, and reusing a tag is fine for a tutorial.

Step 5 — Make the mistake#

Try to instantiate the template into Filler A now.

Nothing happens. No entities are created, and no error is reported.

The reason: the template has not been released. An unreleased template instantiates nothing, silently.

This is the single most common templating surprise, and it is worth experiencing once so you recognise it later — particularly in a build script, where the exit code is 0 and everything downstream then quietly builds against measures that do not exist.

Step 6 — Release, then instantiate#

Release the template metric.

Now instantiate it into Filler A.

Verify the instance completely before doing the other two:

1. Structure — every expected measure is present.
2. Resolved tag — does Bottle Counter point at a tag that exists? Browse the connection and compare.
3. Chain — Counter appears exactly once, then Sum above.
4. Calculation — the expression compiled, and its dependencies point at this instance's measures, not Filler 1's.
5. Values, after deploying — plausible for this equipment.

Item 4 matters. If two instances' calculations both reference the same measure, every instance reports identical numbers and the model is worthless.

Step 7 — Instantiate the rest#

Now Filler B and Filler C. If you are using the CLI, a name and attribute pattern with {0} as the 1-based sequence number does all three in one command.

You now have three fully configured fillers from one definition.

Step 8 — Improve the template#

Add something useful: a rejects chain.

In the Template view, add to the Filler template metric:

Then release the template again — editing does not release it — and update the instances.

Check all three. Each should now have four more measures, with tags resolved to its own attribute values.

That is the payoff. One edit, released once, updated once, and three instances gained a KPI. At twelve instances it is the same amount of work.

Step 9 — Learn what an update overwrites#

Now the important lesson about what survives.

Pick Filler B. Add a purely local measure to its instance metric — something only that filler needs, say Local Note as a manual entry measure.

Separately, edit a templated member on Filler C — change the format on its Bottles Daily, for instance.

Now make another small change to the template, release it, and update all three.

The results:

• Filler B's local measure survives. It has no template link, so an update leaves it alone. This is specialisation, and it is a designed capability — the safe way to handle the one instance that needs something extra.
• Filler C's edit is gone. It was on a templated member, which the template owns, and the update overwrote it.

Step 10 — Understand delinking#

Delink removes an instance's template relationship, leaving everything in place as ordinary local content. It cascades down to child measures.

Use it when a piece of equipment has genuinely diverged and will be maintained independently. Do not use it to escape an update you did not want — the link is not casually recreated, and you lose every future improvement.

If an update did something unwanted, fix the template and update again.

What you have learned#

A template is a class; an instance is an object. The link persists, so improving the class improves every object.

Build one instance properly first.

Release before instantiate. An unreleased template creates nothing, silently.

Editing un-releases. Release again, then update.

Template = shape, attributes = specifics. A template with hard-coded tags is not reusable.

Attribute formatting must match the source exactly.

Verify one instance completely before instantiating the rest.

Updates overwrite templated members and preserve local additions.

Delinking is one-way. Use it deliberately.

Try this before moving on#

Add a chart to the pattern.

Chart templates sit on top of model templates: a chart can only be released as a template when its content is template-linked. Build a chart against a template measure, release it, and derive it for the three instances.

You will find the boundary: charts can be created, configured, and released from the CLI, but instantiating and updating chart instances is a Flow Config activity. Knowing that boundary before you plan a scripted build saves rework.

Next: T13: OEE — the composite KPI everything so far has been building towards.

See also#

• T11: Custom Functions
• T13: OEE
• Templates: Concepts
• Templates: Instantiating and Updating