BaSys 4.2 OPC UA Control Component Profile Server and Compliance Test Tool
This project implements example basys control components with different profiles in an open62541 based OPC UA server.
The goal is to have a dummy for each profile as reference implementation. Moreover, this serves as a test fixture for a profile compliance tool, which is developed as test within this project.
Download
Last builds on master:
Usage
To start an OPC UA server with some examples on localhost and default port 4840 just execute profile_server.
Profiles
BaSys control components may implement the following profiles. They are officialy documented in the basyx wiki. The service interface profile is special, because it is orthogonal to the other profiles. Hence, every other profile looks a bit different, when a different SI profile is realised. A rough implementation status of the examples and tests are marked in the table with -, 0 and +.
Profile | Name | Values | CMD | OPERATIONS | SERVICES |
---|---|---|---|---|---|
SI | Service Interface | CMD, OPERATIONS, SERVICES, VARIABLES | + | + | - |
OC | Occupation | OCCUPIED, PRIO, LOCAL | + | + | - |
EM | Execution Modes | AUTO, SEMIAUTO, MANUAL, SIMULATE | + | + | - |
ES | Execution States | BASYS, PACKML, ISA88, MTP, OPCUA, NE160 | 0 | 0 | - |
OM | Operation Modes | MULTI, PARALLEL, CONTI | + | 0 | - |
For each profile a correspondig enumeration, respectively a bitmask, is implemented in inc/profiles.h
header file.
Some features may be optional, but if used they should be realized in the same way. Therefore the label Optional
is used in tests.
Another keyword is Behaviour
to define tests, that activate operations and check their response and state changes.
Common Profile Values
All profiles can be determined with an positiv integer or zero, respectively enums are implemented. If it is usefull to combine different profile values of one profile, these values are represented as bitmasks. Otherwise normal enums are used.
Bit | Value | Shortname | Example SI | Description |
---|---|---|---|---|
1 | 0 | Unknown | UNKNOWN | No statement or not compliant profile variant |
1 | 1 | None | NONE | Profile is not used or implemented |
2 - n | > 1 | Any | ANY | One ore more profiles. All 2-n bits are linked by or operator (Value > 1) |
2 | 2 | Default | CMD | The default profile variant is used (specific to profile) |
3 | 4 | First | OPERATIONS | Alternative profile variants (specific to profile) |
4 .. n | 8 ..n | Second | SERVICES | Alternative profile variants (specific to profile) |
Service Interface Profiles
Different examples with different service interface (SI) profiles are available. The following profiles are available at the moment:
- CMD: A string variable called CMD (CommandInput) is used to activate service operations.
- OPERATIONS: A list of OPC UA methods in a folder represent the operations of the offered services.
Possible Upcomming SI Profiles
- SERVICES: Each service represents an own object, with OPC UA methods as operations and additional state variables.
- VARIABLES: A list of variables to start the different operations of the offered services.
- MTP: Modulte Type Package conform service interface. Possibly a specific version of the VARIABLES profile.
Profile Compliance Testing
This project includes the google test framework (https://github.com/google/googletest) for unit tests. These tests are designed to be fed with an external opcua server and nodeId of a control component. Hence, they can be used to determine whether a control component has a compliant interface. Moreover filters can be applied to check for specific profiles.
Compliance Test Usage
To test the compliance you need to execute the test_compliance execuatable, which can be found in the bin folder after build process or in the prebuild executables. The other test executables are not needed and are for unit tests and self checks of the profile_server example.
Parameter | Description | Used for | example |
---|---|---|---|
--selfcheck | Use of internal server implemantation | Selfcheck of test_compliance with code from profile_server | --selfcheck |
--server opc.tcp://<host>:<port>
|
URL of OPC UA Server | To specify the internal or external server endpoint | --server opc.tcp://localhost:4840 |
--nodes ns=<index>;[i|s|g|b]=<id>[, ...]
|
List of node ids[1] | Specification of control components (or types respectively interfaces) endpoint | --nodes "ns=1;i=5,ns=2;s='StringNodeId'" |
--namespace <URI>
|
Namespace URI | Search for the namespace index of the profiles information model (to tranlate browse paths) | --namespace "basys40.de/cc/profiles" |
--siProfile <UNKNOWN|CMD|...|0|1|...>
|
SI profile value[2] | Specification of the SI profile to test the nodes against. (Numerical or String) | --siProfile CMD |
--timeout <time>
|
Timeout for behaviour tests (s) | The behaviour test waits this time before checking results for each order | --timeout 5 |
--user <username> <password>
|
Client authentification[3] | The test client logs in with the first user name password given. | --user tester testersPassword |
--gtest_... | Google test framework parameters | Filtering profiles or single tests | --gtest_list_tests --gtest_filter=*ES.* |
[1] Note on node ids: Currently only numeric and string ids are supported.
Single quotation marks are needed to ignore the semicolon in the node id string.
String node ids may enclose the string identifier with quotation marks, e.g.: --nodes 'ns=1;s="/TechUnits/ESE/ControlComponent1"'
[2] Note on common siProfile values: The common values for the SI profile (UNKNOWN, NONE, ANY) are treated in the following way:
- UNKNOWN (0, default value): All tests - All tests for all SI profiles are executed. This may be used to determine which SI profile a control component implements or whether it implements multiple profiles. You can filter tests to specific profile values or tests via gtest_filter.
- NONE (1): ANY tests - The control component implements no compliant SI profile. Only the tests (testname starting with
ANY
) common to all profiles are executed. - Other si specific values (2-n): ANY tests & profile specific - The control component implements one or more specific SI profile values. The tests common to all si profiles (testname starting with
ANY
) and the specific ones are executed. - In future versions the test suite may try to evaluate which profile is used or try to read the
SIPROFILE
OPC UA variable of the control component and assume its value.
[3] Note on user authentification: A second authentification for the OC.*_Behaviour tests with SI OPERATIONS facet is necessary to test against wrong authentification. If no second user is given the anonymous user is used. If no user is given at all the default values from open62541 (user1:password, user2:password1) are used.
Compliance Test Usage Examples
Some simple examples usage scenarios:
- To list all tests:
./test_compliance --nodes i=0 --gtest_list_tests
- To check your filter use:
./test_compliance --nodes i=0 --gtest_list_tests -gtest_filter=FooBlah
- To run a self check with all tests:
./test_compliance --selfcheck --nodes 'ns=1;i=1'
- To test one control component against SI profile OPERATIONS:
./test_compliance --nodes 'ns=1;i=42' --server=opc.tcp://192.168.0.12:4840 --siProfile CMD
GUI Tools for Compliance Testing
The google test framework has different associated projects for GUIs or IDE integration of gtests. Feel free to use one with the test_compliance executable.
Compliance Test Filtering
In general the underlying gtest framework exposes different hierarchical levels to identify tests.
Here three of these levels are used: the instanciation name, the test suite or fixture name and the test name itself.
They are combined in the following way: nodeId/profile.profileValue_keyword
These levels can be used to filter the corresponding test needed for your compliance check:
Level | Used for | Values |
---|---|---|
Instanciation name | Node id | Node Id in standard syntax: `ns=;[i |
Test suite / fixture | Profile | SI, OC, EM, ES, OM |
Test name | Profile Value* | ANY or profile specific values. |
Keyword | _Optional, _Behaviour |
*Some tests are common to all profile values. These tests start with the test name ANY.
Examples of a full test names are:
ns=1;i=10001/ES.BASYS
ns=2;s=MyControlComponent/SI.ANY
ns=3;i=42/OC.OCCUPIED_Optional
Compliance Test Filter Examples
Execute for example: ./test_compliance --server=opc.tcp://192.168.0.100:16664 --nodes i=0 --gtest_filter=
with the following filters:
gtest_filter= | Description of selected tests |
---|---|
*/SI.ANY* |
Service interface profile with all common tests. |
*/SI.CMD* |
Service interface profile with value CMD only |
*/EM.AUTO*:*/EM.MANUAL* |
Execution modes AUTO and MANUAL within EM profile |
-*_Optional |
Exclude checks for optional values. |
Filters may be concenatet with a colon (:). Negative filters are also possible with minus (-) to exclude tests. See google test framework documentation for details.