The Information Model defined for OPC UA FX can be applied in many different manners. To help illustrate some of these options, this annex provides examples for each part of the OPC UA FX Information Model. This includes individual Assets examples, individual FunctionalEntity examples and examples of an AutomationComponent that includes both Assets and FunctionalEntities.

The task of modelling an Asset is more than just describing a single simple Asset. It is modelling the relationships between the Assets. In OPC UA, relationships can be modelled as References, where a Reference provides semantic information about the relationship. OPC UA has defined a number of References in OPC 10000-23 that can be used for modelling Assets. This list is extended by this document. The following ReferenceTypes will be illustrated in various examples in this annex:

• HasContainedComponent indicates that an Asset has another Asset contained in it.
• HasBuiltInAsset indicates that an Asset has an integrated Asset, which is not removable.
• HasPart indicates that an Asset has another Asset which can be removed.
• HasAttachedComponent indicates that an Asset has physically/mechanically attached an Asset.
• IsPhysicallyConnectedTo (symmetric) indicates that two Assets are physically connected to each other.
• ConnectedTo (symmetric) indicates that two Assets are connected to each other by an electrical cable.
• IsPartOfRedundantAssetSet indicates that an Asset is part of a group of Assets that form a redundant Asset.

Additional References may be defined or used to show additional relationships.

Figure D.1 shows a simple single-board computer, in this case, a Raspberry Pi (“Raspberry Pi is a trademark of Raspberry Pi Ltd”), that can be modelled as an asset. This simple single-board computer has multiple items that can be modelled. It has many connector options, including extension boards or external devices and cables. The figure also includes a possible base asset model for the Raspberry Pi. This model does not include all features of a Raspberry Pi, but will be used to illustrate the available ReferenceTypes. This single-board computer could be modelled in many manners, and this illustrates just a possible model. Alternate models could exist and would not be wrong.

Figure D.1 – Raspberry Pi Asset type example

The MyRaspberryPiType is a subtype of FxAssetType. It mandates some of the Optional IVendorNameplateType Properties (all items listed), and it omits other Optional Properties from the interfaces that do not apply to MyRaspberryPiType. The model includes a number of Connectors that are used to add additional peripherals. The MyRaspberryPiType includes a System-On-Chip Object as an illustration of a HasBuiltInAsset. This Object contains information about the CPU and memory. It contains two Variables: one for the CPU Clock rate (can be 1.5 GHz or 1.8 GHz) that is used in the single board computer, and the other is an enumeration of the memory (can be 2, 4, or 8 GB).

The model does not include all the connectors that are available in a Raspberry Pi, but it does show the USB connectors and the external asset that is connected via a cable. See Figure D.2, showing the cable being attached to one of the USB ports. The figure also illustrates the resulting instance model. This figure only includes the instance information related to the ConnectedTo Reference; it does not include all of the other mandatory items that would be in the instance. The USB cable is represented by the ConnectedTo Reference. The Adaptor is its own Asset and might have its own configuration that is omitted here.

Figure D.2 – MyRaspberryPiType Instance with connection

The Raspberry Pi also has a slot for an SD card, which is also modelled (see Figure D.3). The SD card is visible from the outside and can be removed. It is modelled as a HasAttachedComponent. The SD card can also be updated; thus, the SD card model includes the optional SoftwareUpdate component. The SD card is not a top-level Asset, and thus, it does not implement the IDeviceHealthType interface.

Figure D.3 – MyRaspberryPiType Instance with SD card Slot

An alternate manner in which the SD Card could have been modelled is illustrated in Figure D.4. This model does not show the slot since it is assumed that the card is always present. Vendors can generate multiple models, all of which are correct.

Figure D.4 – MyRaspberryPiType Instance with SD Card

The Raspberry Pi might also include extension boards such as the Sense HAT (see https://www.raspberrypi.com/products/sense-hat/ for more information) that is illustrated in Figure D.5. This removable type of extension board could be modelled using a HasPart Reference. In the resulting model, the SenseHat is not a top-level Asset but just a child of the GPIO connector that it is attached to. This addition provides a number of sensors – a gyroscope, accelerometer, magnetometer, humidity sensor, barometric sensor, temperature sensor and an LED display.

Figure D.5 – MyRaspberryPiType Instance with a Sensor Hat

The Raspberry Pi can also be enclosed in a case which also contains a fan (see Figure D.6). The fan is wired to the single-board computer. Both the Raspberry Pi and the fan are physically attached to the case. The case is not modelled as an Asset, but it can still make use of the References defined in OPC 10000-23.

Figure D.6 – MyRaspberryPiInstance as part of larger model

Figure D.7 illustrates the entire Information Model for the Raspberry Pi described in this annex.

Figure D.7 – Raspberry Pi complete Asset model

Let’s look at a possible asset model for a rack into which controllers, power supplies and I/O modules are inserted. The rack may be cabled to an extension rack, where the extension rack holds additional I/O modules. The rack is illustrated in Figure D.8.

Figure D.8 – Rack based device illustration

This main rack could be modelled in a number of manners. Figure D.9 illustrates one possibility. The figure is not complete in that not all subcomponents or details are included. The model has a base rack model (MyRackType) that can represent any rack, including the Subunit. The base rack does include redundant power supplies. The main unit is modelled (MyMainRackType) as a subtype of this rack. The main unit includes a CPU, which is mandatory and always sits in Slot1.

Figure D.9 – Rack model illustration

Figure D.10 illustrates the model for the CPU module. This model is based on interfaces and includes software update functionality. It also provides a variable that represents the temperature of the CPU (and the engineering units associated with the temperature). The CPU model also provides an enumeration that represents the status of the CPU module (Failed, Degraded, Normal). This status is used as an indicator light on the module.

Figure D.10 – CPU Model illustration

Figure D.11 illustrates the IO Module model. This IOModuleType is a subtype of FxAssetType. The model includes a StatusIndicator that behaves exactly the same as the CPU Model StatusIndicator (Figure D.10). The model also supports software updates. The model includes a folder for connectors, where the connector provides connections to external IO. These connectors may be of any type, depending on the type of connected IO device. It is expected to be further subtyped. This model reflects specific types of external IO connections and devices.

Figure D.11 – IO Model illustration

Figure D.12 illustrates the power supply module. This model is just a base object that exposes the required interfaces. The PowerSupplyType has a reduced set of IVendorNameplate properties. PowerSupplyType provides a Variable that reflects the power output of the supply. PowerSupplyType also has a variable that reflects the temperature. PowerSupplyType, as with all of the modules, includes a status indicator.

Figure D.12 – Power supply model illustration

Figure D.13 provides an illustration of a deployment of this model. The instance provides an additional CPU and includes several IO modules. The figure also illustrates the values of some of the variables in the various models. The figure omits many variables and values for simplicity. These variables would exist in the actual complete model. The model does not describe the devices that are connected to the IOP modules. This model is used for additional examples.

Figure D.13 – Instance of Rack example

A Client may verify whether an Asset meets the expectations of system engineering. This example demonstrates how to use verification. It uses the rack example.

Figure D.14 – Sample for Assets of a chassis-based controller

Figure D.14 illustrates the Assets of a rack-based controller. The vendor modelled a 12-slot rack with Connectors, a communications module, and two controllers (CPU) modules. The IsPhysicallyConnectedTo Reference indicates that the modules are plugged into slots 1 & 2, whereas slot 3 is unused. IO modules are plugged into slot 4, slot 6, slot 7 and slot 10.

Assume that all CPU Assets are manufactured by the same manufacturer as the rack and have their ManufacturerUri set “http://ACME.com”.

Assume that the Descriptor contains for CPU1: ProductCode “ZY456”, MajorAssetVersion “2”, MinorAssetVersion”4”, and SerialNumber “N475655”, and for CPU2: ProductCode “YY544”, MajorAssetVersion “2”, MinorAssetVersion”7”, and SerialNumber “Z234545”.

A Client checking for compatibility of the Assets Controller1 and Controller2 by using VerificationMode AssetCompatibility will set the ExpectedVerificationVariables in VerifyAsset to the values as stated above, without the given SerialNumbers. The SerialNumbers should be added when using VerificationMode AssetIdentityAndCompatibility.

If the verified Assets match the expected values exactly, i.e., ManufacturerUri, ProductCode, MajorAssetVersion, and MinorAssetVersion are identical, Match will be returned. For example, if Controller2’s actual MinorAssetVersion is set to “9” but the Asset is still compatible with MinorAssetVersion “7”, Compatible will be returned.

The VerifyAsset Method allows doing additional verification besides verifying the Asset itself using ExpectedAdditionalVerificationVariables.

Figure D.15 – Asset Verification example – Asset location

Consider, for example, verifying whether an IOModule (NetIO-1) is plugged into Slot7. This can be done, as illustrated in Figure D.15, by using a relative path as:

<HasComponent>Assets

<Organizes>NetIO-1

<IsPhysicallyConnectedTo>Slot7

<HasVariable>Id

The Client can verify that NetIo-1 is physically connected to Slot7 by resolving this relative path. The VerifyAsset Method may now be used by the Client to verify that the resolved Node has a value of 7.

Figure D.16 – Verify Asset example – external device

This same concept can also be used to verify Assets that might not be directly linked to the AutomationComponent, i.e., they are not in the Assets folder but only referenced from existing Assets( see Figure D.16). In this example, the BrowsePath would look like:

<HasComponent>Assets

<Organizes>IoBlock2

<HasComponent>Connectors

<HasComponent>Slot1

<IsPhysicallyConnectedTo>DeviceX

This process could also be used to verify the values of configuration settings such as EngineeringUnits.

This clause provides examples of functionality that a FunctionalEntity might expose. This includes Inputs, Outputs, ControlGroups and the resulting Connections. It will also describe the use of pre-configured DataSets and dynamically created DataSets.

In later clauses, these examples are linked to the Asset examples to provide a more complete picture.

The following types of References provided with this document and OPC 10000-23 are used for modelling FunctionalEntities:

• HasSubFunctionalEntity indicates that a FunctionalEntity has a nested FunctionalEntity.
• IsHostedBy indicates that a FunctionalEntity needs the referenced Asset to provide its functionality.
• IsExecutingOn relates a FunctionalEntity to the execution environment it is currently executing on (e.g., hardware component, task or thread).
• RepresentsSameEntityAs (symmetric) relates two entities which represent the same entity in the real world. This Reference may be used, for example, to relate a FunctionalEntity with its counterpart in the event of redundant logic. Another example might be a sensor that is dual-ported and wired to two different input signals. These two FunctionalEntities could be related with RepresentsSameEntityAs.
• RepresentsSameFunctionalityAs (symmetric) relates two entities representing the same functionality. This Reference may be used, for example, to relate a FunctionalEntity with its counterpart in a companion specification.

Figure D.17 provides an example FunctionalEntity model that could be applied to the single-board computer from the Asset example (MyRaspberryPi). The model shows a subtype of FunctionalEntityType that represents an execution engine that can run generic function blocks. The ExecutionEngineType includes the capability of loading libraries of function blocks, where each function block would be a FunctionalEntity. The model includes a Method that is used to load function block libraries and a Method to load a program that is executed by the ExecutionEngine. ExecutionEngineType will be used to illustrate various aspects of the FunctionalEntity model in the following clauses.

Figure D.17 – FunctionalEntity for MyRaspberryPi example

Figure D.18 provides an example of an instance of the ExecutionEngineType. It is empty in that no libraries or programs have been loaded. The model does show the AuthorUri for the ExecutionEngine (Http://Opcfoundation.org), an AuthorAssignedIdentifier (FLCEx01) and an AuthorAssignedVersion (1.0.0.0). The ApplicationIdentifier is set for the empty ExecutionEngine (ExecEngine01 with a program code of 26). The execution engine also has a default setting for BlockCount, 0 – it is empty. CycleInterval in Millisecond of 100. The status also indicates nothing is loaded.

Figure D.18 – FunctionalEntity base instance example

Figure D.19 illustrates an ExecutionEngine in which libraries have been loaded as well as a program. There are two libraries loaded. One that provides the functionality that comes with the SenseHat (note: not all functionality is illustrated) and another that provides calculation functions. These libraries can be thought of as a list of types that can be instantiated in programs. A program is also loaded, where the program is a sub-FunctionalEntity (MyApplicationProgram), and each execution block is represented by a separate FunctionalEntity (Temperature, Humidity, Calculation, and LED-Block).

Some key points in this example, the ApplicationIdentifier has been updated for each application that was loaded since each was provided by a different vendor. The Sub FunctionalEntities all have their own AuthorUri and other properties, but they are not illustrated for simplicity. Also, each FunctionBlock has a list of inputs, outputs and configuration data that is also not illustrated. This illustration will be used in later clauses to illustrate other concepts.

Figure D.19 – Example FunctionalEntities for RaspberryPi

InputData and OutputData can be modelled in various ways. The following clauses show examples of their usage. Figure D.20 illustrates the subtype of FunctionalEntityType that is used in the example. All items listed are mandatory in this subtype, but not all of these items will be shown in the examples to simplify the example figures. The AcmeAnalogueInputModuleType illustrates a hardware module that collects data from external input devices, where this information is made available to the controller. This AcmeAnalogueInputModuleType is external to the FunctionalEntity model; think of it as an existing Information Model. The FunctionalEntity then publishes this data to another controller, HMI, or even other devices as needed.

Figure D.20 – Example FunctionalEntity Type

The following examples illustrate how InputData and OutputData can be joined with DataSets. Consider, for example, an analogue input module with four channels plugged into one of the slots of the rack illustrated in D.2.3. The FunctionalEntity related to this Asset will provide OutputData only. To keep the following samples simple, ConfigurationData (e.g., measurement range and unit) is not shown. The dashed lines in figures in this clause indicate “poor man’s references” instead of an actual Reference. The line will indicate if the poor man’s reference is using a NodeId or a Name.

The first variant, as illustrated in Figure D.21, assumes that the module can only exchange data using a preconfigured DataSet containing all four channels. In this case, a possible Information Model would organize the Variables in OutputData (the top-level folder). The preconfigured PublishedDataSet PDS_AI4 defines the fixed layout for the data exchange (indicated in PublisherCapabilities as one of the PreconfiguredPublishedDataSets). PreconfiguredDataSetOnly set to True indicates that the data contained in this folder can only be exchanged using the preconfigured PublishedDataSet.

Figure D.21 – Sample for analogue input module – pre-configured DataSet only

This has the consequence that a ConnectionEndpoint established on that FunctionalEntity can only use the preconfigured PublishedDataSet for communication, as illustrated in Figure D.22. Conn_A and the PubSub Objects, including DSW_A (referencing the preconfigured PDS_AI4) are in this example created during EstablishConnections. For simplicity, PubSubConnection and WriterGroup are not shown.

Figure D.22 – Fixed layout used by ConnectionEndpoint

The second variant assumes that the module can exchange data using a preconfigured DataSet containing all four channels but also allows data to be exchanged using a customized DataSet (e.g., Channel2 and Channel3 to one controller and Channel1 to another controller).

In this case, a possible Information Model looks like the one illustrated in Figure D.23. However, PreconfiguredDataSetOnly set to False indicates that the data can be exchanged using the preconfigured PublishedDataSet, but in addition using a customized DataSet. A customized PublishedDataSet will be created during the establishment of a connection.

Figure D.23 – Sample for analogue input module – preconfigured and customized DataSet

ConnectionEndpoints established on that FunctionalEntity may use a preconfigured or customized DataSet as illustrated in Figure D.24. Conn_A, Conn_B, DSW_A, DSW_B and PDS_B are created in this example during EstablishConnections. ControllerA, connected through Conn_A, will receive all channels using the preconfigured PublishedDataSet PDS_AI4. ControllerB, connected through Conn_B, will receive Channel2 and Channel3 using the customized PublishedDataSet PDS_B.

Figure D.24 – Preconfigured and customized DataSet used by ConnectionEndpoints

A third variant assumes that the module supports data exchange with customized DataSets only.

In this case, a possible Information Model looks like the one illustrated in Figure D.25. However, the absence of PreconfiguredPublishedDataSets indicates that only customized DataSets are supported.

Figure D.25 – Sample for analogue input module – customized DataSets

Subfolders within the OutputData can be used, for example, to group data. Suppose that our sample module is an 8-channel input where a channel can be Int16 or Float. A possible Information Model is illustrated in Figure D.26.

Figure D.26 – Sample for analogue input module – using groups

Again, as stated in the variants before, the module may choose to support preconfigured DataSets (e.g., one for all Int16 channels and one for all Float channels) and/or allow customized DataSets, depending on the setting of PreconfiguredDataSetOnly. A Connection may, for example, select Channel1 and Channel6. Figure D.27 illustrates this sample.

Figure D.27 – ConnectionEndpoint using grouped data

ControlGroups can be used for many purposes. They can illustrate related functionality or be used to establish control. Establishing control of a ControlGroup can be done by calling the Method EstablishControl or by using the EstablishControlCmd with the EstablishConnections Method. The following clauses provide examples of their usage.

Figure D.28 shows the FunctionalEntity for a simple temperature monitor based on the Raspberry Pi Sense HAT (see Figure D.5). The FunctionalEntity provides the output Variable Temperature, indicating the current temperature. It also includes a Variable EngineeringUnit (e.g., °C, °F, °K…). This configuration variable allows the selection of the engineering unit for the Temperature.

Figure D.28 – Sample FunctionalEntity for a simple temperature monitor

While using the Temperature, the EngineeringUnit for the Temperature should not change. To achieve this behaviour, the ControlGroup MonitorControl is provided. The EngineeringUnit is contained in the ListToRestrict to ensure that changes are restricted to the owner of the ControlGroup. Temperature is contained in the ListOfRelated to indicate that Temperature is part of the ControlGroup.

Assume that the Raspberry Pi (see D.2.2) is used for an automated guided vehicle (AGV) using the Sense HAT and some motors attached through the connectors. Figure D.29 illustrates a sample FunctionalEntity representing this simplified AGV.

Figure D.29 – Sample FunctionalEntity for a simplified AGV

The Information Model offers two alternatives using a normalized value or raw data for controlling SpeedSetpoint and monitoring SpeedActual, Orientation, and Compass. Since both alternatives should not be used at the same time, two ControlGroups, ControlNormalized and ControlRaw, are added to the functional model (see Figure D.30).

Figure D.30 – ControlGroups added to the functional model

Each of the ControlGroups represents an interface provided by the FunctionalEntity to control and monitor the AGV using normalized or raw data. The interface is represented by the ListToRestrict and ListOfRelated References. By this, the InputData, OutputData, ConfigurationData, and all provided Methods belonging to the interface can be easily determined. The ListToBlock prevents the setting of specific data, for example, SpeedSetpointNormalized, when controlling the AGV with raw data. The ListToRestrict prevents usage of the Method and setting of MaxAcceleration and SpeedSetpoint from anyone except the owner when controlling the AGV.

Since ControlNormalized and ControlRaw share Variables in their ListToRestrict, usage of them at the same time is only possible with the same owner.

ControlGroups can be used with Connections.

Assume that the EngineeringUnit of Temperature (see Figure D.28) should not change during the lifetime of a Connection. A connection configuration to achieve this behaviour would establish the control of MonitorControl using the EstablishControlCmd, set the EngineeringUnit with the desired unit (e.g., °F) using the SetConfigurationDataCmd, and reassign control to the ConnectionEndpoint using ReassignControlCmd.

A Client is able to verify whether a FunctionalEntity meets the expectation of system engineering. This example demonstrates how to use verification.

Figure D.31 – Sample for a FunctionalEntity

Figure D.31 illustrates a simple FunctionalEntity. The author defining the AcmeFEType provides mandatory input and output Variables (a, b, c, and d) and optional Variables x and y.

The author-defined type of a FunctionalEntity is uniquely identified by AuthorUri, AuthorAssignedIdentifier, and AuthorAssignedVersion. Therefore, a Client using the Verify Method may pass the following ExpectedVerificationVariables:

• PortableNodeIdentifier=“AuthorUri”, Value =“http://acme.org”
• PortableNodeIdentifier=“AuthorAssignedIdentifier”, Value =“7852-14”
• PortableNodeIdentifier=“AuthorAssignedVersion”, Value =“1.2”

Since the author decided to provide optional Variables, an instance of this type may or may not provide x or y. To verify whether Variable x exists, a Client may pass the following ExpectedVerificationVariable:

• PortableNodeIdentifier=“x”, Value =null

The ApplicationIdentifier allows the identification of a specific instance of a FunctionalEntity and (if provided) any customization by using a name (for user representation) and a unique ID (for verification). A sample for customization is a drive or a process automation device that was configured by a specific engineering tool. A Client may pass the following ExpectedVerificationVariable:

• PortableNodeIdentifier=“ApplicationIdentifier”,[0] Value =“537a9b43-5c84-4aaa-a105-a04fab2ba5b6” [1] Value=“827a9d43-8e86-6bcd-1256-b03fdc7ab9d3”.

Figure D.32 illustrates other items that might be validated.

Relative paths may also be used for verifying the FunctionalEntity. For example, a Client may verify whether CalcBlock is provided by the correct AuthorUri or that a configuration variable is set to a correct value, as illustrated in Figure D.32.

Figure D.32 – Additional verification items

Figure D.33 provides an illustration of a full AutomationComponent. It omits some instances in nested Objects. This example links the Asset illustrated in D.2.2 for the SenseHat (Figure D.5) with the FunctionalEntity example in D.3.3 for the SenseHat (Figure D.19). It shows the IsExecutingOn Reference between the MyApplicationProgram FunctionalEntity and the MyRaspberryPiInstance Asset.

Figure D.33 – AutomationComponent example

Figure D.34 provides a zoomed-in view of the AutomationComponent MyRaspberryPiAC. It illustrates the multiple Descriptors that the AC exposes. One for the original Raspberry Pi application, one for the SenseHat library that provides functionality, and one for the end user application (user program) that is loaded. It also illustrates the ConformanceName URL that points to the OPC Foundation listing for the product. Since this sample is a certified application, the URL would provide the details related to the Profile/Facets and optional ConformanceUnits related to this product’s certification.

Figure D.34 – AutomationComponent expand example