The following use cases describe how base features are supported by the FDT OPC UA system architecture.
|
Use Case |
List Topology |
|
|
Description |
The OPC UA client shows the topology in a hierarchical tree to the user. The tree is provided by an OPC UA server for FDT OPC Information Model. If the OPC UA server supports a network topology, it is provided according to the 'Device Integration Host Model' defined in OPC UA DI. |
|
|
Stakeholder |
|
|
|
Preconditions |
Topology is available in OPC UA Server |
|
|
Post conditions |
User can see the topology in a hierarchy |
|
|
Actors |
Engineer, Expert, Observer |
|
|
Trigger |
Whenever a user needs a list of devices for further access |
|
|
Frequency |
|
|
|
Description |
|
|
|
|
Step |
Action |
|
|
1 |
User triggers connect from OPC Client to OPC Server |
|
|
2 |
User starts browsing from node 2:DeviceTopology |
|
|
3 |
OPC Client displays the topology to the user |
|
Exceptions |
|
|
|
Requirements |
User has access permissions to the server |
|
|
Notes |
Network/communication topology Physical topology |
|
|
Open Issues |
|
|
|
Use Case |
Identify Device |
|
|
Description |
A user gets information about a physical device selected in a topology. The OPC UA client provides this information to the user by reading identification information provided according to the FDT OPC UA information model. |
|
|
Preconditions |
Topology and device node is available in OPC UA Server |
|
|
Post conditions |
|
|
|
Actors |
Engineer, Expert, Observer, Plant Asset Manager |
|
|
Trigger |
Whenever a user needs information about a device |
|
|
Frequency |
|
|
|
Description |
||
|
|
Step |
Action |
|
|
1 |
User browses namespace to a node representing a device |
|
|
2 |
User starts reading identification information of the device |
|
|
3 |
OPC Server obtains information about the device from associated DTM |
|
|
4 |
OPC Client displays the identification values to the user |
|
Exceptions |
|
|
|
Requirements |
User has access permissions to the server |
|
|
Notes |
|
|
|
Open Issues |
|
|
|
Use Case |
Browse device parameters. |
|
|
Description |
OPC Client has the UI windows for displaying the device details information. If the device has the blocks, the UI window displays block names which the device has. If a device has blocks, the UI window displays parameter names which are included in blocks. If a device does not have a block, the UI window displays parameter names which the device has. |
|
|
Stakeholder |
Mass Configuration |
|
|
Preconditions |
Use Case B.2 (List Topology) |
|
|
|
|
|
|
Post conditions |
On the OPC client, user can see the parameter names which the device or the block has. |
|
|
Actors |
Engineer, Expert, Observer, Plant Asset Manager |
|
|
Trigger |
Whenever a user needs a list of parameters for further access. |
|
|
Frequency |
|
|
|
Description |
||
|
|
Step |
Action |
|
|
1 |
On OPC Client, user opens a UI window of a device which is selected on the topology which is listed by the Use Case B.2. |
|
|
|
|
|
|
2 |
User browses a name list on the selected device in the OPC Client. |
|
|
3 |
OPC Server retrieves a name list of the selected device. |
|
|
4 |
OPC Client displays a name list to user. If selected device has blocks (if the device is FF-H1 or PROFIBUS PA), OPC Client displays the block name list. |
|
|
5 |
User selects an item in the name list, and user browses the selected item (block name list or parameter list). |
|
|
6 |
If the object type of selected item is “Block”, OPC Server retrieves available parameters of the selected block. |
|
Extension |
||
|
|
Step |
Branching Action |
|
|
4 |
OPC Server gets the attributes (Label Name / Help Description) of the selected item in the list and displays in the OPC Client. |
|
Variations |
||
|
|
Step |
Branching Action |
|
|
4 |
If selected device has no blocks (if the device is HART), OPC Client displays the parameter name list. |
|
|
6 |
If the object type of selected item is “Parameter”, OPC Server retrieves available attributes of the selected parameter. For the enumeration case, an OPC Client displays the corresponding label with the value. |
|
Exceptions |
Step 2, The device is not ready to communicate. |
Step 3, The DTM which is browsed does not provide a block list (if the device is FF-H1) or a parameter list. |
Step 6, If the object type of selected item is “Parameter Element”, OPC Server does not return a list. OPC Client displays a message informing user that there are no available items. |
|
Requirements |
User has access permissions to the server |
|
|
Notes |
[Hierarchy of items] [Up to the parameter] FF-H1 / PROFIBUS PA : {Device} --- {Block} --- {Parameter} HART : {Device} --- {Parameter} [Up to the element] FF-H1 : {Device} --- {Block} --- {Parameter} --- {Element(*)} (*) Element = the member variable of the structure [Up to the enumeration] FF-H1 / PROFIBUS PA : {Device} --- {Block} --- {Parameter} --- {Enumeration} FF-H1 : {Device} --- {Block} --- {Parameter} --- {Element} --- {Enumeration} HART : {Device} --- {Parameter} --- {Enumeration} |
|
|
Open Issues |
|
|
|
Use Case |
Get attributes of a device parameter |
|
|
Description |
OPC Client has the UI windows for displaying the device details information. The UI window displays parameter names, its’ engineering units and values (if the parameter is readable). When OPC Client displays the value of a parameter, the value is displayed according to the “display format“, which is described in the DD. If the OPC Client also has the parameter-write-function and if the parameter is writable, an UI-element for writing the value to a parameter is displayed. |
|
|
Stakeholder |
Mass Configuration |
|
|
Preconditions |
Topology and device node are available in OPC UA Server Device is connected to the OPC UA Server. OPC Client gets the parameter list of a device from OPC Server. To display the parameter name and its value, OPC Client tries to get the detail information of each parameter. |
|
|
Post conditions |
On the OPC client, user can see the parameter names, and can see the detail information for each parameter. Detail Information of parameter: the data type, the label name, the minimum value, the maximum value, the engineering units, writable, readable, the enumeration list, the display format, the edit format. |
|
|
Actors |
Engineer, Expert, Observer, Plant Asset Manager |
|
|
Trigger |
Whenever a user needs the attributes of parameters for further access. |
|
|
Frequency |
|
|
|
Description |
||
|
|
Step |
Action |
|
|
1 |
OPC Client requests to get the attributes of a parameter of a device to OPC Server. |
|
|
2 |
OPC Server gets the attributes of the parameter which is specified by OPC Client from the device DTM. |
|
|
3 |
OPC Client displays the parameter name to use the label name, and the engineering units. |
|
Exceptions |
Step 1, The specified parameter does not exist in the device. |
|
|
Requirements |
|
|
|
Notes |
To use the attributes of a device parameter which is gotten by this use case, OPC Client can work as follows. [For read parameter] OPC Client can recognize a parameter is readable or not, and then OPC Client gets the value of the parameter via OPC Server from the device. OPC Client displays the corresponding label with the value if the data type of a parameter is the enumeration, otherwise (if the data type is not the enumeration) OPC Client displays the value according to the “display format“. [For write parameter] OPC Client can recognize a parameter is writable or not, and then OPC Client can check the entered value whether the data type, and the minimum value and the maximum value of the entered value are correct or not when user tries to write a value to a parameter. |
|
|
Open Issues |
|
|
|
Use Case |
Get Device Status |
|
|
Description |
DTM can provide the NE107 status as the device status by the next procedure. Reading the data from the device parameters which express the device status or the results of the diagnosis of the device. Calculating the bits and mapping to the NE107 status definition. |
|
|
Stakeholder |
Mass Configuration |
|
|
Preconditions |
Client connected to OPC Server. |
|
|
Post conditions |
OPC Client can display NE107 status as the device status. |
|
|
Actors |
Engineer, Expert, Observer, Plant Asset Manager |
|
|
Trigger |
Whenever a user needs the device status information of the device. |
|
|
Frequency |
|
|
|
Description |
|
|
|
|
Step |
Action |
|
|
2 |
User triggers to retrieve device status of a device in OPC Client. |
|
|
3 |
OPC Client requests to get the diagnosis parameter/s of a device to OPC Server. |
|
|
4 |
OPC Server retrieves the device status from the DTM |
|
|
5 |
DTM reads the value of the diagnosis parameter/s of a device and calculates the status |
|
|
8 |
OPC Client displays the NE107 status of the device. |
|
Exceptions |
Step 4, No diagnosis parameter/s are defined, if the DTM does not support to retrieve the diagnosis parameter/s. |
|
|
Requirements |
|
|
|
Notes |
|
|
|
Open Issues |
|
|
|
Use Case |
Get Device Diagnostic Information |
|
|
Description |
A software or user requests diagnostic information (context specific diagnostic information) from a physical device. The OPC UA client collects this information by reading device diagnostic information provided according to the OPC UA DI information model. |
|
|
Stakeholder |
|
|
|
Used by |
|
|
|
Preconditions |
Device node is available in OPC UA Server Device is connected to the OPC UA Server (means online or only somehow accessible?) Use case B.2 (List Topology) |
|
|
Post conditions |
Maintenance or asset manager can derive actions |
|
|
Actors |
Engineer, Expert, Observer, Maintenance Manager, Asset Manager, Operator |
|
|
Trigger |
Status of device is not Good. This information is provided by: Use case B5 or by alarms |
|
|
Frequency |
|
|
|
Description |
||
|
|
Step |
Action |
|
|
1 |
OPC Client User opens UI of the device |
|
|
2 |
User requests diagnostic data of the device |
|
|
3 |
OPC client requests diagnostic data of the device from the OPC server |
|
|
4 |
OPC server gets diagnostic data from the DTM |
|
|
5 |
OPC server sends the diagnostic data to the client, displaying the data on the UI |
|
Exceptions |
|
|
|
Requirements |
|
|
|
Notes |
According to FDT2.0 the expectation is, that the DTM provides the parameters for device specific diagnostic within one group of parameters. |
|
|
Open Issues |
|
|
|
Use Case |
Read offline parameters |
|
|
Description |
A software or user requests device parameter (the last set values) from a DTM. The OPC UA client collects this information by reading device parameter from the offline set provided according to the FDT OPC UA information model. |
|
|
Stakeholder |
|
|
|
Preconditions |
Device node is available in OPC UA Server and the Client already knows the ParameterIds of the Parameters to read (may have been retrieved according to use case B4.2). |
|
|
Post conditions |
Client knows the current value of device parameters |
|
|
Actors |
Engineer, Expert, Observer, Operator |
|
|
Trigger |
Whenever the data is needed |
|
|
Frequency |
|
|
|
Description |
||
|
|
Step |
Action |
|
|
Preparation |
The OPC Client selects the respective device node and the parameter set of the device. |
|
|
1 |
OPC Client executes Read-Service (one or multiple times) with the list of identifiers for the respective device parameters (list of ParameterIds) and the list of AttributeIds for Value and (at least once) for DateType. |
|
|
2 |
OPC Server retrieves the requested attributes (e.g. value) of the parameter which are specified in the Read-Request from the DTM (instance data set) and returns them to the client. |
|
|
5 |
OPC Client displays the parameter value (or uses it otherwise). |
|
Exceptions |
Step 1, The specified parameter does not exist in the device. |
|
|
Requirements |
|
|
|
Notes |
|
|
|
Open Issues |
|
|
|
Use Case |
Read online parameters |
|
|
Description |
A software or user requests device parameter (the current values in the device) from a DTM. The OPC UA client collects this information by reading device parameter from the online set provided according to the FDT OPC UA information model. |
|
|
Stakeholder |
|
|
|
Preconditions |
Device node is available in OPC UA Server and the Client already knows the ParameterIds of the Parameters to read (may have been retrieved according to use case B4.2). |
|
|
Post conditions |
Client knows the current value of device parameters |
|
|
Actors |
Engineer, Expert, Observer, Operator |
|
|
Trigger |
Whenever the data is needed |
|
|
Frequency |
|
|
|
Description |
||
|
|
Step |
Action |
|
|
Preparation |
The OPC Client selects the respective offline device node |
|
|
1 |
OPC Client selects the online device and the parameter set of the online device. |
|
|
2 |
OPC Client executes Read-Service (one or multiple times) with the list of identifiers for the respective device parameters (list of ParameterIds) and the list of AttributeIds for Value and (at least once) for DateType. |
|
|
3 |
OPC Server requests the requested attributes (e.g. value) of the parameter which are specified in the Read-Request from the DTM (instance data set). |
|
|
4 |
The DTM retrieves the current values from the device and returns them to the server. |
|
|
5 |
OPC Server returns the requested information to the client. |
|
|
6 |
OPC Client displays the parameter value (or uses it otherwise). |
|
Exceptions |
Step 1, The specified parameter does not exist in the device. |
|
|
Requirements |
|
|
|
Notes |
|
|
|
Open Issues |
|
|
|
Use Case |
Writing Online Device Parameter |
|
|
Description |
The OPC client allows configuring or updating parameter values on the device. Writing is executed from an OPC client to an OPC server providing the FDT OPC UA information model. |
|
|
Stakeholder |
|
|
|
Preconditions |
Use Case B1 (List Topology) |
|
|
Post conditions |
OPC client can retrieve the updated device parameter values |
|
|
Actors |
Field Engineer, Device Expert, Maintenance Engineer |
|
|
Trigger |
Device Commissioning, Device Calibration, Device Configuration |
|
|
Frequency |
|
|
|
Description |
||
|
|
Step |
Action |
|
|
2 |
User starts browse from Device Topology |
|
|
3 |
OPC Client displays the topology to the user |
|
|
4 |
User browse the parameters on the selected device |
|
|
5 |
OPC Client displays available parameters on the device |
|
|
6 |
User selects the device parameter that the value needs to be updated or changed |
|
|
7 |
User changes the value of the selected device parameter based on its type |
|
|
8 |
User commits the changes |
|
|
9 |
OPC server puts the lock on the device |
|
|
10 |
OPC server validates the specified parameter value |
|
|
11 |
OPC server writes the updated value to the device |
|
|
12 |
OPC server removes the lock on the device |
|
|
13 |
OPC client displays the new value of the selected device parameter |
|
Exceptions |
Step 7, Value does not match the data type of the device parameter. |
Step 8, Device is in locked state. |
Step 10, Value exceeds the minimum and maximum limit specification of the device parameter. |
|
Requirements |
User has access permissions to the server |
|
|
Notes |
|
|
|
Open Issues |
|
|
|
Use Case |
Audit Trail |
|
|
Description |
A central Audit Trail system logs audit events from FDT based tools. All auditable actions in the FDT tool produce OPC UA Audit Events and the central Audit Trail system subscribes for OPC UA Audit Events from the tool. |
|
|
Used by |
|
|
|
Preconditions |
Audit Events are supported by the OPC UA Server |
|
|
Post conditions |
Configuration changes are logged in the central Audit Trail. |
|
|
Actors |
Administrator for central Audit Trail system, Engineer, Expert |
|
|
Trigger |
Whenever device configuration actions must be logged in an audit trail |
|
|
Frequency |
|
|
|
Description |
||
|
|
Step |
Action |
|
|
1 |
Define configuration changes that create an audit event in the OPC UA Server and FDT Frame |
|
|
2 |
Activate Audit Events in the OPC UA Server |
|
|
3 |
Configure central Audit Trail system to subscribe for audit events from the FDT OPC UA Server |
|
|
4 |
Log configuration changes in the central Audit Trail system |
|
|
5 |
View Audit Trail through a tool that comes with the central Audit Trail system |
|
Exceptions |
|
|
|
Requirements |
|
|
|
Notes |
|
|
|
Open Issues |
|
|
_____________