About the license pack file (LPF)

LPFs are created on the Niagara License Server as part of the license record for the FLR. Note the following points about the LPF.

LPF characteristics

The name of the file is fixed and bound to the hostId of the system. The file name format for an LPF is as follows: <hostId>.lp
The LPF is a “signed” file that you should NOT edit.
The FLR always starts running if it has a valid node-locked license but it does not serve licenses if the LPF is not valid.
Any updated licensing (for example, to change a port number for the FLR) requires the generation of a new LPF. When the new license (with the same name) is installed, the previous LPF is overwritten by the new license. While running, the FLR periodically checks the LPF to make sure that it has not changed. If a change is detected, the FLR attempts to reload the new (changed) file. If the port has changed, the FLR restarts itself on the new port. This prevents multiple FLRs from running on the same host.
The FLR allows the LPF to be reloaded without requiring a restart.

Refer to Figure 3 and the following list for descriptions each of the major blocks of the LPF:

Figure 3. Example LPF

<lpf vendor="Acme" generated="“2010-01-31"
expiration="2011-01-31">    <flr hostId="hostId" port="19110" />
  <packs>
      <pack name="station" limit="10">
    <licenses>              </licenses>    </pack>
      <pack name="wb" limit="20">
    <licenses>              </licenses>
</pack>        <pack name="energy"
limit="2">      <licenses>...</licenses>    </pack
>  </packs>    <signature>signed by Licensor</signature></lpf>

LPF elements and attributes

<lpf> element

This element is the top level element for the LPF. It includes attributes for defining the “vendor” name, file “generated” date, and an “expiration” date for the LPF.
<flr> element

This element contains the configuration for the FLR that it uses when it starts. The “hostId” attribute value is necessary to prevent starting FLRs on unauthorized hosts. The “port” attribute is specified to prevent multiple copies from running on the same host.

If you ever want to change the port that the FLR is running on, a new LPF must be generated and downloaded from Niagara License Server (or sent by email).
<packs> element

This element is the parent for one or more individual license packs that can be served by the FLR. See <pack> element, below.
<pack> element

All <pack> elements are uniquely named packs, using the “name” attribute. These may be anything; they are simply identifiers for license configurations. The content of a <pack> element is the same content as the traditional NiagaraAX license file. For example, an LPF may have three packs: a "station" pack a "workbench" pack, and an "energy" pack. The floating NREs use the pack name to request a license from the FLR.

All <pack> elements have a “limit” attribute that specifies the maximum number of application instances that can use this pack. For example, consider the "station" pack in the LPF in Figure 3. It has a "limit" attribute of 10 which means that only 10 NREs can have this pack checked out at any given time. Inside each pack is a single <licenses> XML element.
<licenses> element

The <licenses> block is basically a standard Niagara license with a few modifications. All the licenses in this block (and their features) are sent to a floating NRE when it leases the "station" pack. There is only one set of licenses defined in each pack. There is not a limited number of licenses in a pack. This means that each floating NRE that requests the "station" pack gets the same license. However, this license is never written to disk and does not work as a stand-alone license.

Refer to the NiagaraAX User Guide for more details about the standard NiagaraAX license file.