OPC UA.Net Reference Implementations

UA SDK 1.00.231.1 Readme January 4, 2009 Overview The UA SDK is a set of interfaces, libraries and executables that allow developers to quickly create UA applications with the .NET programming environment. The SDK includes: * Implementations of the XML Web Services and UA Native Binary stack profiles; * Server and Client development toolkits; * Sample Applications; * A wrapper for COM-DA Servers (DA 2.05a, DA3.00 and AE1.1); * A proxy for COM-DA and COM-AE clients (DA 2.05a and AE1.1); * Local Discovery Server; * Configuration Tool The sample applications are available with source code. The stack and development toolkits are available only as binaries. Release Notes Build 231.1 incorporates updates to the UA diagnostics information model (now completely implemented). This release of the SDK supports the release candidates for Part 4 and Part 6. The release candidates for Part 4 and Part 6 are available on the UA SharePoint Collaboration Site. Users should use Mantis to report any issues/bugs. This will also allow users to find issues identified by others. Copyright and License Information The redistributables and source code are covered by the general OPC Foundation license agreement which can be found here. This license agreement will be replaced by one specific to the UA SDK before the SDK released. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/) Release Process This release introduces a new 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. Installers The SDK is now distributed in a number of different packages which are described in the table below: OPC UA SDK 1.00 Redistributables MergeModule (x86) Installs the UA Local Discovery Server and the UA Configuration Tool The UA Local Discovery Server is installed as a Windows Service that starts automatically on startup starts automatically on startup The executables are placed in $(CommonFilesFolder)\OPC Foundation\UA\ Setting the UA_COM_INTEROP property installs the assemblies used by the COM wrappers and proxies. The executables are placed in $(CommonFilesFolder)\OPC Foundation\UA\v1.0\Bin\OPC Foundation\UA The COM client applications will need access to OpcUaComDllHost process which is registered as a COM EXE server. Setting the UA_DOTNET_SDK property installs all files required to build applications that use the .NET version of the stack. Assemblies and documentation are placed in $(ProgramFilesFolder)\Reference Assemblies\OPC Foundation\UA\v1.0 Setting the UA_ANSIC_SDK property installs all files required to build applications that use the ANSI C version of the stack. Headers and libraries are placed in $(CommonFilesFolder)\OPC Foundation\UA\v1.0 Setting the UA_OPENSSL_SDK installs all files required to build applications that use the OpenSSL library used by the ANSI C stack. Headers and libraries are placed in $(CommonFilesFolder)\OPC Foundation\UA\v1.0 Only the DLL version of the OpenSSL libraries are installed. OPC UA SDK 1.00 Redistributables Setup (x86) Installs all of the redistributable files It prompts the user to choose which components are installed. OPC UA SDK 1.00 Sample Binaries Setup (x86) Installs the binaries for the sample applications. OPC UA SDK 1.00 Sample Source Code Setup (x86) Installs the source code for all of the samples. 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