View Issue Details

IDProjectCategoryView StatusLast Update
000229510000-006: Mappingspublic2013-01-22 19:45
ReporterNathan PocockAssigned ToRandy Armstrong  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Fixed in Version1.03 
Summary0002295: Handling/Replacing of NaN with NaN should cause DataChange notifications
Description

CMPWG 11/29/2012:

The following text comes from an email circulation that occurred yesterday (11/29/2012) and contains all information:

Hello everyone,

I have concluded my testing and wanted to share the results with you. Today we learned (CMPWG) that NaN is a special value that cannot be compared to itself, i.e. “NaN == NaN” will return FALSE. There are typically special operators/methods for comparing NaN such as “isNan(value)” in Javascript. We have a test-case that follows the IEEE guidelines which we needed to test in order to determine if UA spec updates are needed. I tested JavaScript’s compliance with IEEE and found that it is compliant, i.e.
var a = NaN;
var b = NaN;
print( a == b ); // prints “false”;
print( a === b ); // prints “false”;
print( isNaN( a ) ); // prints “true”;

Our test case, and expected results:

  1. Create a Subscription and add a MonitoredItem (use a data-type of Double)
  2. Call Publish to get the initial value
  3. Write NaN
  4. Call Publish; expect a DataChange to contain the NaN value.
  5. Write NaN again
  6. Call Publish, and again expect a DataChange to contain the NaN value since NaN != NaN (per IEE) and therefore constitutes a data-change.

Test results are as follows:
• PASSES. Unified Automation UaDemoServer (1.3.2.200): Complies with IEEC. A DataChange was received on both occasions with an item value of NaN.
• FAILS. Softing Toolbox OPC UA Server (5.21): Initial data-change received when value changed to NaN, but not subsequent writes of NaN.
• FAILS. Prosys UA Server (Java) (1.4-5518): Writing NaN returns Good_CompletedAsynchronously, but never actually completes. Read returns prior value. DataChange discussion irrelevant.
• FAILS. OPC Foundation UA Sample Server (334): Writing/Reading NaN is good; initial DataChange received with NaN, but not subsequent Writes of NaN do not yield DataChanges.

Conclusion: We have 1 out of 4 platforms that work in accordance with IEEE. We should test the stack from EmbeddedLabs also. It seems like we need a clarification (errata) to the UA Specs (p4?p6?) regarding the handling of NaN.

The CTT script used in testing is shown below this email.

Question: Do we agree to add a Mantis to UA Part 4/6 requesting commentary on handling NaN per IEEE requirements? Or revise the test-case?

Thanks everyone,

Nate.


/* Test prepared by Nathan Pocock; nathan.pocock@opcfoundation.org (29-Nov-2012)

Description: 
    Write NaN, call Publish; do this twice. A DataChange is received both times.

*/

function test023()
{
var item = AnalogItems[0];
const ERR_NAN_EXPECTED = "KeepAlive received. Expected a DataChange in Publish because NaN is always unique, even \"NaN == NaN\" returns False";
const ERR_NOT_NAN = "Did not receive NaN; expected NaN.";
const OK_NAN_RECEIVED = "Publish.Response.NotificationMessage.DataChange.MonitoredItems[0].Value = NaN as expected.";

// read the value 
ReadHelper.Execute( { NodesToRead: item } );

// create a subscription and add the item to it 
var sub = new Subscription();
if( CreateSubscriptionHelper.Execute( { Subscription: sub } ) ) { 
    if( CreateMonitoredItemsHelper.Execute( { ItemsToCreate: item, SubscriptionId: sub } ) ) { 
        // get the initial Publish and DataChange 
        wait( sub.RevisedPublishingInterval );
        PublishHelper.Execute();

        // do our test twice
        for( var i=0; i<2; i++ ) { 
            // set the value to NaN
            item.SafelySetValueTypeKnown( NaN, item.Value.Value.DataType );

            // write a NaN
            if( WriteHelper.Execute( {
                            NodesToWrite: item, 
                            ReadVerification: true } ) ) {

                // call Publish, get a DataChange 
                wait( item.RevisedSamplingInterval );
                PublishHelper.Execute();
                if( AssertTrue( PublishHelper.CurrentlyContainsData(), ERR_NAN_EXPECTED ) ) { 
                    AssertTrue( isNaN( PublishHelper.CurrentDataChanges[0].MonitoredItems[0].Value.Value ), ERR_NOT_NAN, OK_NAN_RECEIVED );
                }
            }// if( WriteHelper.Execute
        }// for( var i=0; i<2; i++ ) 
        // clean-up
        PublishHelper.Execute(); // ack the last sequence
        DeleteMonitoredItemsHelper.Execute( { ItemsToDelete: item, SubscriptionId: sub } );
    }// if( CreateMonitoredItems.Execute( { ItemsToCreate: item } ) )
    // clean-up
    DeleteSubscriptionsHelper.Execute( { SubscriptionIds: sub } );
}// if( CreateSubscription.Execute( { SubscriptionId: sub } ) )

}

safelyInvoke( test023 );

TagsNo tags attached.
Commit Version
Fix Due Date

Activities

Ustinov Vetcheslav

2012-12-04 07:54

reporter   ~0004354

More critical issue - deadbands.
For example:
"NaN - AnyValue > deadband value" evaluates to false.
"AnyValue - NaN > deadband value" evaluates to false.

Thomas Merk

2012-12-12 09:26

reporter   ~0004372

From my point of view a change from a NaN to the same NaN (same bit pattern) does not require a notification.

However every change in bit pattern should be notified.
If detection of a change is related to the bit pattern and not restricted to NaN also changes between +infinitiy, -infinity, +0.0, -0.0, ... would be detected and notified.

Of course any change between a valid number and any other bit pattern (and vice versa) should be notified independent to deadband.

Randy Armstrong

2012-12-29 15:55

administrator   ~0004379

Added text to OPC UA Part 6 - Mappings DRAFT 1.03.01 Specification

Jim Luth

2013-01-22 18:19

administrator   ~0004425

Reviewed and modified text 1.03.02 in meeting.

Issue History

Date Modified Username Field Change
2012-11-30 15:09 Nathan Pocock New Issue
2012-12-04 07:54 Ustinov Vetcheslav Note Added: 0004354
2012-12-11 18:16 Jim Luth Status new => assigned
2012-12-11 18:16 Jim Luth Assigned To => Randy Armstrong
2012-12-12 09:26 Thomas Merk Note Added: 0004372
2012-12-29 15:55 Randy Armstrong Status assigned => resolved
2012-12-29 15:55 Randy Armstrong Resolution open => fixed
2012-12-29 15:55 Randy Armstrong Note Added: 0004379
2013-01-22 18:19 Jim Luth Status resolved => closed
2013-01-22 18:19 Jim Luth Note Added: 0004425
2013-01-22 19:45 Jim Luth Fixed in Version => 1.03