View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
000488330070: MTConnectApi Changepublic2019-07-26 21:252021-01-06 16:20
ReporterDoug Stewart Assigned ToWilliam Sobel  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Fixed in Version2.00.01-Amendment 1 
Summary0004883: I think the MTConnect standard's usage of Mapping the Native Code to a Condition Branch is a semantic mismatch
Description

While mapping an MTConnect NativeCode to the OPC UA Conditoion BranchID my technically allow OPC UA to represent all the possible states of the MTConnect system, it is semantically not the same meaning, and standard OPC UA Client tools, will create misleading views of these systems states.

From the OPC UA Spec Part 9 page 5:
Condition instances are specific implementations of a ConditionType. It is up to the Server whether such instances are also exposed in the Server’s AddressSpace. Clause 4.10 provides additional background about Condition instances. Condition instances shall have a unique identifier to differentiate them from other instances. This is independent of whether they are exposed in the AddressSpace.
As mentioned above, Conditions represent the state of a system or one of its components.

The different native Codes in MTConnect represent different conditions. They do not represent ID's for previous occurrences of the same condition. Each NativeCode is a different condition. Each native Code will have a different operator action to resolve, there is no notion of the them representing previous occurrences of interest of the same condition like the OPC UA BranchId.

From the OPC UA Spec Part 9 Page 5:
In certain cases, however, previous states that still need attention also have to be maintained. ConditionBranches are introduced to deal with this requirement and distinguish current state and previous states. Each ConditionBranch has a BranchId that differentiates it from other branches of the same Condition instance. The ConditionBranch which represents the current state of the Condition (the trunk) has a NULL BranchId.

Steps To Reproduce

1) Read and understand Part 9 of the OPC UA specification.
2) Read and understand OPC 30070-1: OPC UA for MTConnect
3) Think.
4) Think some more.
5) Try to visualize how an OPC UA client would represent Condition Branches give the normal OPC UA meaning for them.
6) Consider if that is the correct visualization for what MTConnect realy means.
7) Realize that MTConnect is misusing the semantic meaning of BranchID's

TagsNo tags attached.

Activities

William Sobel

2019-09-08 02:05

developer   ~0010915

Last edited: 2019-09-08 02:09

The following is the propsed change for mapping MTConnect conditions to OPC UA Conditions:

  • Remove mention of branching for MTConnect Branches.
  • The EventType instance is mounted in the address space and has the MTConnect Condition metadata as properties and an Active State Variable (ActiveState).
  • The EventType instance in the address space will set ActiveState = true when an MTConnect Condition has Warning or Fault.
    • When the MTConnect Condition reports Normal for all MTConnect Condition instances, then ActiveState = false.

Event Handling:

  • An event is generated for each transition of MTConnect Fault or Warning.
  • Each MTConnect Condition Fault or Warning creates a new UA Event – for each unique MTConnect condition by nativeCode w/ ActiveState = true. (match nativeCode).
  • Each MTConnect Condition Normal creates a new UA Event – for each unique MTConnect condition by nativeCode w/ ActiveState = false. (match by nativeCode to previous activation).

We could have a aggregate Fault or Warning State Variable that aggregates reports if any Warnings or Faults are currently active. MTConnect provides the list of active Warnings and Faults for any Conditon by type for a current request. Events can be queried to provide same functonality.

The change will not require any substantive change except for the removal of the branch references and the generation of new events when a Warning or Fault occurs.

Stan Brubaker

2020-08-21 18:24

manager   ~0012704

This change has been officially released in an Amendment and Errata against 2.0 of the specification.

Issue History

Date Modified Username Field Change
2019-07-26 21:25 Doug Stewart New Issue
2019-08-23 18:45 Stan Brubaker Assigned To => William Sobel
2019-08-23 18:45 Stan Brubaker Status new => assigned
2019-09-08 02:05 William Sobel Note Added: 0010915
2019-09-08 02:09 William Sobel Note Edited: 0010915
2020-08-21 18:23 Stan Brubaker Fixed in Version => 2.00.01-Amendment 1
2020-08-21 18:24 Stan Brubaker Status assigned => closed
2020-08-21 18:24 Stan Brubaker Resolution open => fixed
2020-08-21 18:24 Stan Brubaker Note Added: 0012704