Issue will be resolved by creating a new embedded server facet that does not inherit from Core Server Facet. Need to get more feedback on any other things that should be removed from Core Server Facet for embeded (security for example).

Randy will get more feedback from the source of the request.

If you build an OPC UA / ADI server which has to publish a 1 KPts spectrum every 2 seconds AND you want to survive to a disconnection of 10 minutes, requesting a minimum of 10 sessions will put a lot of pressure on the embedded server. If you put on top of that the encryption, the result will be that everybody will want to implement a "Low End Embedded Device".
The "goal" of Embedded versus Low End Embedded should be clarified:
1) Is it for small sensors or actuators (only few tags with very limited processings)?
2) Is it for a small number of clients?
3) Is it to avoid using security? Putting to much pressure on Embedded Server will push in the field more unsecure servers!
4) Is it to avoid Subscription support?

For example, most of the actual PC embedded in current analyzers will be barly able to sustain two ADI connections without security and one with security. But for ADI, so forcing an Embedded Sever to 10 connections will create a lot of problems and cost.
If this decision is maintained, the ADI spec shall be updated to move from Embedded Server to Low End Embedded server.

We have proposed that the profiles be reorganised as follows (exact details will be provided to Randy in a few days time):

Standard UA Server (50-sessions)
+- Embedded UA Server (10-sessions)
+- Micro Embedded Device Server (5-sessions)
+- Nano Embedded Device Server (1-session)

Security would be optional for Micro and Nano Server Profiles (it is presently optional for Micro).

Enhanced Datachange Subscription Server (500-Monitor Items, 5-Subscriptions, 10-Publish)
+- Standard Datachange Subscription Server (100-Monitor Items, 2-Subscriptions, 5-Publish)
+- Embedded Datachange Subscription Server (10-Monitor Items, 1-Subscriptions, 2-Publish)

The subscription facets would be optional for Nano and Micro Server profiles (although in practice many device vendors will want to support the Embedded Datachange Subscription Server facet).

We see Micro Embedded Devices as devices such as single axis servo-amplifiers. They have many hundreds of internal parameters but access is only required to a small number of these parameters at any point in time by a very small number of clients.

Nano Embedded Devices are sensor type devices that are exposing a very small number of data values via an aggregator.

Security and subscriptions are very important features, but they are not necessary for every application and to mandate their support in all devices would prevent UA adoption in a large number of device categories.

The key features that really need to be optional in the Nano Profile are multiple sessions, subscriptions and security. Each of these features has the potential to push bill of materials costs up to an unsustainable level in the presence of competing technologies.

Here is an example of an actual OPC UA implementation of a small spectrometer analyzer that shall be moved to ADI.

The configuration is:

• AMD Geode processor (kind of 586 class processor)
• Windows CE or Windows XP embedded
• Perform data spectroscopic analysis to convert analyzer data to some
  meaningfull values
• Generate a spectrum every second, which is an array of 1000 float points
  plus let say 20 other values
• Using the Ascolabs OPC UA C++ SDK, without security, it already requires
  80% of the CPU for a single session
• One client subscribing to the spectrum and 20 values

Also, it shall be noted that many of these systems work with WiFi connection that I would say are not that stable:

• Drop out of few seconds
• Brownout
• Long disconnections; up to 2 hours in some cases

The previous configuration can sustain a disconnection of 2 hours without loosing anything, not a single element. So in terms of robustness, it is important to have longer monitoring queues or WiFi subscription will not be reliable at all.

As you can see, we may perhaps ask for light encryption and two sessions, but certainly not 10 sessions.

Also, it is probably a good idea to express the monitoring queue size in terms of seconds rather than count when no data shall be lost due to disconnection

Also in the case of ADI, the number of monitored items is more defined by what is located in the AcquisitionResult and
AcquisitionStatus folders that is published with each acquisition.
The minimal content of these folders are defined by the ADI specification, but each vendor may and will add more.

Based on the previous comment, the ADI definition will be:

• Nano Server
• Minimum monitoring queue size should be at least 60s
• The server shall be able to handle as many items as the AcquisitionResult
  and the AcquisitionStatus folders contain

If I have to do a trade off, I will increase the monitoring queue size and decrease the session count.
The Liam Power proposal looks fine to me:

• Standard Server 50
• Embedded 10
• Micro 5
• Nano 1

Updated to reflect smaller requirements of core and added addition numbers to large profiles

Closed by UA Weekly Telecon 2010-05-04