The ServerCapabilities->ModellingRules object should not be empty because the stack uses modellingrules.

[northernlig]

Type of issue

• Bug
• Enhancement
• Compliance
• Question
• Help wanted

Current Behavior

The stack currently does not populate the servercapabilities->modellingrules folder with the rules that are used by the stack in the populated datatypes addresspace. This means that all servers need to add these modellingrules manually to be compliant and it places the reference server in a state where it is not compliant.

Additionally, adding modellingrules is difficult because it requires adding nodes that are defined by Opc.Ua.Nodeset.xml but not exposed in the code.

Expected Behavior

The folder should contain any modellingrules (and their namingrules) that the stack utilizes. At least these modellingrules are used by the stack: Mandatory, Optional, OptionalPlaceholder, and ExposesItsArray. It's possible ManditoryPlaceholder is used as well, but I was unable to find its use. To see these, browse the references of many of the nodes in the Types folder of the addressspace and look for the "HasModellingRule" reference type.

A nice-to-have would be the ability to add/override modellingrules when a server wishes its own ruleset. A server should define all rules used, so the stack may not necessarily use all the rules that a server would ultimately use.

Steps To Reproduce

1. Spin up the quickstart reference server.
2. Navigate to the ServerCapabilities->ModellingRules folder and expand. Notice it's empty when it should not be empty.

Environment

- Server:  Reference Server (anything that uses the server really)
- Runtime: .NET 6.0
- Component: Opc.Ua.Core

Anything else?

The requirement for including all used modellingrules is described in the spec here:
"ModellingRules is an entry point to browse to all ModellingRules supported by the Server. All ModellingRules supported by the Server should be able to be browsed starting from this Object."

We believe following the implementation used by the AggregateManager is ideal as a precedent. This solution solves a few problems:

• By default it populates the nodes expected by the stack.
• It is overridable within StandardServer.CreateAggregateManager such that server that want different behavior can modify the nodes that are registered.
• The supported nodes are defined and accessable within Opc.Ua.Constants.cs. It is important that the namingrules be accessible.