Build 1.01.318.0

[This is preliminary documentation and is subject to change.]

This section contains release motes and summary of changes.

Release Process

This section introduces a release process which is designed to balance the needs of different developers in different stages of development.

The different stages are described in the following table:

Snapshot

Snapshot builds are only minimally tested and are used to give developers quick access to new features and bug fixes. There may be backward compatibility issues and some features may be broken. Developers should not migrate to a snapshot build unless they need the feature and/or bug fixes.

Testing

Testing builds are put through basic tests to ensure that nothing is broken but have not been tested for backward compatibility. All Stable and Final builds are posted first as Testing builds which gives developers a chance to check for issues which can be corrected quickly. Any changes will incorporated into a new revision and posted immediately. If no issues come up the last revision of a Testing build will be re-labeled as Stable or Final. Developers are encouraged to look at Testing builds and see if there are issues. Developers should not migrate to Testing builds unless they absolutely need the functionality or are participating in the testing process.

Stable

Stable builds are put through basic tests to ensure that nothing is broken but have not been tested for backward compatibility. Stable builds are posted to give vendors a chance to verify that it works with existing products. Vendors who have products under development should migrate to stable builds as quickly as possible. If a vendor is already distributing products they may wish to use the sample applications to test for compatibility problems.

Final

Final builds are stable builds that have been verified by one or more vendors. Patches required to fix issues discovered while testing the stable build are applied but no other features are added. Vendors who have products under development should migrate to stable builds as quickly as possible.

Each build is assigned a unique build number that may be qualified with a revision number. The revision number indicates that patches were applied to a build.

Patches may be created to fix critical issues in final builds even if a newer build is available. Vendors will need to upgrade to the newest version if they need fixes for stable or snapshot builds.

All files posted to the website or SharePoint will have the build stage and build number in the file name. For example:

OPC UA SDK 1.00 Redistributable APIs MergeModule (x86) [222.0 Stable].zip

The major version of the SDK always matches the major version of the latest specification that it supports. The minor version is incremented each time new features are added after release.

If a previously posted build needs to be patched the revision number will be incremented. For example, 218.1 is a patch applied to 218.0.

Release Notes

Current release of the SDK supports the release candidates for Part 4 and Part 6.

Part

Release

Paqrt 4

OPC UA Part 4 - Services RC 1.01.30 Specification

Part 6

OPC UA Part 6 - Mappings RC 1.00.08 Specification

Current API Status

There are a number of different APIs embedded within the SDK which are in different states of development.

Each of these APIs has a different development status:

Development

The associated specification is not released and the feature set is not complete. Changes to APIs in this state are quite likely.

Testing

The feature set is complete and basic functional tests have been completed. Changes to APIs in this state are possible (due to bugs or refactoring).

Beta

The feature set is complete and more exhaustive testing has started. Changes to APIs in this state only happen if absolutely necessary.

Released

Testing is complete. Changes to APIs in this state will not happen (i.e. new interfaces/subclasses are created).

The Server SDK APIs sets and their current status are:

IServer/IServerEndpoint

Beta

StandardServer/IServerInternal

Beta

Session

Beta

NodeManager

Beta

NodeSource/BaseEvent

Testing

Subscription/MonitoredItem

Beta

Alarms/Conditions/State Machine

Development

Historian

Development

ApplicationConfiguration

Testing

Configuration Tool Interface

Development

The Client SDK APIs sets and their current status are:

ClientBase/IChannel

Beta

Session

Beta

Subscription

Beta

Condition and Events

Development

ApplicationConfiguration

Testing

Configuration Tool Interface

Development

Known Issues

  • IIS hosted servers have not been tested.

  • Read/Write services do not implement the IndexRange parameter for multi-dimensional arrays and ByteStrings.

  • The Alarms and Conditions specification is a long way from release and the code reflects that.

  • The Query service is not implemented.

  • The information model for the state machines has changed an needs to be incorporated into the codebase;

  • The EventManager does not provide the table of subscribed fields as described in the overview document;

  • The CoreNodeManager does not automatically translate objects that implement ITranslateableObject

  • The AE proxy does not work properly.

Summary of Changes

1.00.230.1 December 6, 2008

Build 230.1 fixes incorrect node identifiers and a bad log file path that could cause the install to fail on some systems.

In addition to a number of bug fixes this release include more examples of custom node managers and an new version of the ModelDesigner which produces classes that can be used in the development of custom NodeManagers.

The old classes output by the ModelDesigner are still supported and the ModelDesigner schema did not change.

This release of the SDK supports the release candidates for Part 4 and Part 6.

Build 224

  1. Incorporated Application Configuration File editing feature back into the Configuration Tool

  2. Replaced the MonitoredItem class with the IMonitoredItem interface. This is a breaking change for servers that implement their own NodeManager, however, it will allow implementers to replace the default MonitoredItem with their own implementation which is optimized for their application.

  3. Replaced the StoreName/StorePath elements in configuration files with StoreType/StorePath. This is a non-breaking change but obsolete warnings will be produced. This change will allow future versions to support non-windows certificate stores.

Build 223

  1. Build environment ported to VS2008

  2. Merge modules merged into one module.

  3. Trace facility now supports filtering for different message types.

  4. Servers now monitor their application configuration file and automatically load changes to security or trace settings (other changes are ignored).

  5. The supported flags are documented in the SampleClient configuration file.

  6. A throughput problem when using HTTP has been fixed. The fix requires that all client processes set the System.Net.ServicePointManager.DefaultConnectionLimit to a number larger than the total number of simultaneous requests that the client needs to send. This should be at least 2 times the maximum number of subscriptions. The sample applications set this value to 25.

Build 222

  1. Changed ApplicationConfiguration.ParseExtension(Type) into a template function ApplicationConfiguration.ParseExtension()

  2. 2) ExtensionFactory.GetXmlName() now supports collection classes with the CollectionDataContractAttribute

  3. Added AE Wrapper to the Opc.Ua.ComInterop library.

  4. Added Utils.SilentDispose helper function.

  5. Added support for IDisposeable to all managers in the Server SDK.

  6. Server now reports the server-side stack traced when a fault occurs in debug mode

  7. Added DiagnosticsMasks to the IMonitoredItem interface.

  8. SamplingGroups are now restricted to single Session.

  9. Removed DefaultOperationContext from IServerInternal

  10. Added DataLock to ILocalNode interface.

  11. Updated C# and ANSI C (binary and XML) decoders to skip unread bytes at the end of extension objects.

  12. Added OpcUa_EncodeableTypeTable_AddUnknownTypeMapping and OpcUa_EncodeableObject_ParseExtension functions to the ANSI C stack to support applications that need to deal with unexpected subtypes of well known data types.

  13. Merged the C++ Opc.Ua.Security library into Opc.Ua.Core which means the SDK will run in 64-bit executables.

  14. Removed the GetEffectiveIdentity/GetPrincipalForIdentity methods from the IServerInternal interface. Developers are now expected to provide the effective identity when validating the user credentials. Applications can do this by handling the ImpersonateUser event exposed by the SessionManager.

  15. Added CreateSecurityTokenResolver and SetWindowsUser static helper methods to UserIdentity.

  16. Moved the user token validation code from the SessionManager to the SampleServer. The SessionManager will accept all valid tokens if the application does not handle the ImpersonateUser event.

  17. Added the TranslationInfo and ITranslationManager interface. Updated ResourceManager to use it. Default ResourceManager now allows applications to manually load translations. ITranslationObject created but not used by the CoreNodeManager yet.

Build 218

  1. Renamed EventNotification to EventNotificationList; Added HistoryEventFieldList with ClientHandlep.

  2. Renamed EventNotification to EventNotificationList; Added HistoryEventFieldList with ClientHandle

  3. Changed DiagnosticInfo.NamespaceURI to DiagnosticInfo.NamespaceUri in XML Schema/WSDLWSDL

  4. Changed StatusCode.Code from a xs:string to an xs:unsignedInt in the XML Schema/WSDL

  5. Fixed problem writing values with data types that are subtypes of built in types

  6. Optimized the reference tables used by the CoreNodeManager

  7. UA Certification Tool has been renamed to UA Configuration Tool. A command line version is available as well.

  8. Added COM proxy configuration capabilities into7) XML serialization behavoir for NodeId and Variant classes changed slightly

  9. The ServiceMessageContext provided to the Channel or Host is now used during XML serialization instead of ServiceMessageContext.GlobalContext

  10. Numerous bug fixes and enhancements added to the ANSI C implementation of UA Secure Conversation

  11. Added ArrayDimensions to the Argument structure

  12. Fixed timing problems during publishing in both the Client and Server SDK

Build 215

  1. Added command line version fo the configuration tool.

  2. Configuration file can now be in any directory (installed in All Users\Application Data by default now)

Build 211

  1. Fixed threading problems within the C# UA TCP implementation;

  2. Completed DA 2.05a CTT testing for the UA-COM proxy server;

  3. Added support for environment variable strings in file paths placed in configuration files;

  4. Incorporated changes to the information model based on reviews of Part 3 and Part 5;

  5. Added publish request limit to the server;

  6. Removed dedicated publish threads in client SDK and tested recovery after network interruption;

See Also

Other Resources