Add s2opc (OPC UA implementation) module to Zephyr

[vla3913]

Introduction

s2opc is an open-source implementation of the OPC UA protocol.

Zephyr and S2OPC have some common points:

• focused on security and safety (it is written to get certifications)
• Apache 2.0 license
• tailored for embedded systems

S2OPC nano server has been certified by the OPC Foundation.
On the security aspect, a CSPN evaluation is in progress at the initiative of the ANSSI (https://www.ssi.gouv.fr/en/).

Problem description

OPC UA is the machine to machine protocol of industry 4.0. If Zephyr target is IOT products, it is important to have an OPC UA library and if possible, a library which share its concerns (safety, security, open-source, ...).

Proposed change

S2OPC, hosted on Gitlab used to run on Linux, Windows, FreeRTOS or VX Works.
We ported the library on Zephyr. The result is available on the Gitlab.
There are still some modifications/improvements to be done but we would like to share our first results.

Detailed RFC

S2OPC sources contain a directory src/Common/helpers_platform_dep which contain all platform dependent code (timers, threading, etc ...). There is sub-directory per supported platform.
A Zephyr sub-directory has been created and we tried to map our abstraction layer to Zephyr API.

OPC UA contains two different mechanisms:

• the classic client/server which is connected and based on TCP
• the PubSub which is not connected and based on UDP, MQTT, AMQP or Raw Ethernet.

A demo server, result of the porting activity has been successfully tested on imx1064 with Zephyr 2.2.
We plan to test qemu_x86 and others hardware architectures using Renode.

Proposed change (Detailed)

We suggest using S2OPC for the name of the module.
The project is hosted on Gitlab but we have a GitHub mirror.
In order to facilitate future maintenance, our favorite option would be the creation of the branch zephyr on Gitlab which is mirrored on GitHub and you can integrate into Zephyr but we are open to discussion.

At first, we suggest submitting the library code plus a demo server as a sample.

It is running successfully on Zephyr zephyr-v2.3.0-520-gba0a791635c9 with imx 1064 and native_posix

Dependencies

s2opc main dependencies are:

• mbedtls for cryptographic operations
• operating systems services, and especially communication (TCP, UDP, ...)

Concerns and Unresolved Questions

We have still some unresolved issues including:

• s2opc needs the system time to check the date of certificates. We tried to use the POSIX API to get system time we encountered an issue (C standard library <time.h> functions and structures not available when using POSIX API #24730). As a temporary workaround, we use binary build date as current system date.
• UDP PubSub is based on multicast UDP. This feature doesn't seem to be managed by Zephyr (IPv4 - Multicast Join/Leave Support #2336). We modified the Kernel to support UDP multicast at least for native Posix and imx1064 (See Multicast emission is only possible for ipv4 starting with 224. #26584 and suggested patch for imx1064 IPv4 multicast datagrams can't be received for mimxrt1064_evk board (missing ethernet API) #26585)

Alternatives

N/A

[vla3913]

cc @carlescufi @puchm. Request for a module sent.

[vla3913]

To test the module (at your own risk, it is a beta version).

1/ Add the following lines into west.yml:

name: s2opc
path: modules/lib/s2opc
url: https://gitlab.com/systerel/S2OPC
revision: zephyr

2/ run west update

3/ go to directory zephyrproject/modules/lib/s2opc/samples/ClientServer/zephyr/toolkit_test_server and run west build. Note: the default board is imx1064.
The generated application is a demo server OPC UA which is exposed on URL opc.tcp://192.0.2.10:4841.

[jukkar]

* UDP PubSub is based on multicast UDP. We tried to port it with IPv4 but stopped as this feature doesn't seem to be managed by Zephyr (#2336)

It would not be a big task to create IPv4 join/leave multicast support. Atm I am quite busy with other areas but I can help if someone wants to implement this.

[puchm]

@vla3913 the revision "plu_poc_zephyr_imx6_rebase" is not in the repo anymore... Which should I use instead? I tried "zephyr" but that got me an error when building.
And is it possible to simply supply -b qemu_x86 to the build command in order to build it for Qemu? Or are there some other things that make it default to imx1064?

[vla3913]

@puchm. Yes you are right: the branch was renamed this morning to be closer to Zephyr standard. I am going to update the content of the issue.
The default target is imx1064 because it is our development target and we have not tested yet others ones.
But you can test others architectures. For examples for imx1020, the following command successfully build a binary I cannot test:

west build -p auto -b mimxrt1020_evk

and for qemu_x86:

west build -p auto -b qemu_x86

[vla3913]

@puchm which Zephyr revision do you use ? We develop against Zephyr revision 2.2.

[vla3913]

However, if i am not wrong, QEMU x86 emulator doesn't support Ethernet so I don't think it's the good platform to test the library.

[jukkar]

QEMU x86 emulator doesn't support Ethernet

qemu_x86 most definitely supports Ethernet. We have Intel e1000 driver in Zephyr which is also supported by Qemu. You can setup TAP Ethernet device in Linux and connect that to Zephyr running in Qemu, this is very useful in testing.

[vla3913]

@jukkar, it's really good news !
Reading https://docs.zephyrproject.org/2.2.0/boards/x86/qemu_x86/doc/index.html, and seeing Ethernet in the unsupported features list, I thought it was not the case but it looks like I have missed something.

[jukkar]

@vla3913 Ethernet seems to be missing from supported features list, but if you scroll down, the networking support is mentioned separately.
https://docs.zephyrproject.org/2.2.0/boards/x86/qemu_x86/doc/index.html#networking

[puchm]

@vla3913 I was using Zephyr 2.2.99, I switched to 2.2.0 and it worked.
What I think would be quite useful is an explanation on how to access OPC UA that runs in QEMU from "outside". So for example one could set up a server in their Qemu environment and then try to access it, for example using opcua-client-gui. From what I have been reading, I think that it is somehow necessary to set up a network bridge but I didn't really succeed.
I guess developing in an emulation like Qemu is quite important for many developers because it could speed up the workflow.

[jukkar]

From what I have been reading, I think that it is somehow necessary to set up a network bridge but I didn't really succeed.

The zephyr documentation describes how to setup qemu<->host communication using Ethernet here https://docs.zephyrproject.org/latest/guides/networking/networking_with_host.html

I was using Zephyr 2.2.99, I switched to 2.2.0 and it worked.

Was there something in 2.2.99 that did not work, or did you just want to use the 2.2?

[jukkar]

I think that it is somehow necessary to set up a network bridge but I didn't really succeed.

Bridging is only needed if you want to connect two Zephyr instance (for example two Qemu) to each other.

[vla3913]

@puchm, you are absolutely right, we are working on the subject. Following the advice of @jukkar, I compiled in qemu-x86 and added a zeth interface.
The good news is the connection part works perfectly. I am able to communicate between the OPC UA server in QEMU and an OPC UA client on my desktop.
The bad news is the connection is not established because (Thanks GDB by the way) mbedtls refuses to initialize (mbedtls_ctr_drbg_seed returns an error). We are going to investigate this issue.

[puchm]

Sorry for the late reply.
@jukkar compiling didn't work with Zephyr 2.2.99 for some reason and I didn't investigate it further. It worked in 2.2.0 which is why I decided to use that. It may be worth trying it in 2.3.0 when that's done but that's something I don't have time for right now.
I tried using the networking stuff (I used "Native Posix Internet", https://docs.zephyrproject.org/latest/samples/net/eth_native_posix/README.html) but I am getting an error when compiling:

In file included from /usr/include/bits/errno.h:26:0,
                 from /usr/include/errno.h:28,
                 from /home/moritz/zephyrproject/zephyr/include/kernel.h:18,
                 from /home/moritz/zephyrproject/zephyr/arch/posix/core/offsets/offsets.c:26:
/usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file or directory
 #include <asm/errno.h>

What I did is I ran Zephyr net-tool's net-setup.sh with sudo and then I built the usual way with the board parameter being native_posix.
How did you get this to run @vla3913 ?
Also, I didn't really understand what you mean by saying the connection works but is not established... What does this mean for the functionality of S2OPC?

[vla3913]

@jukkar, we run into structure and functions prototypes which seem to be modified since revision 2.2 (aka _k_thread_stack_element structure or k_sleep function ). What do you suggest: always align to the master or stick to 2.2 ?
@puchm, i get this to run by compiling in qemu-x86 and using e1000 driver:

west build -p auto -b qemu_x86 -- -DOVERLAY_CONFIG=overlay-e1000.conf

then, launch net-tool in a terminal:

net-setup.sh

and finally run the binary:

west build -t run

What I mean is that I am able to exchange Ethernet messages with the Zephyr application running in Zephyr but the OPC UA communication is not established because of an mbedtls initialization error i do not have on real hardware (mbedtls_ctr_drbg_seed initialization error)

[jukkar]

we run into structure and functions prototypes which seem to be modified since revision 2.2 (aka _k_thread_stack_element structure or k_sleep function ). What do you suggest: always align to the master or stick to 2.2 ?

The 2.3 release will contain big changes for timeout functionality so functions like k_sleep are affected. If you still want to use the old timeout code, just enable CONFIG_LEGACY_TIMEOUT_API.
I am probably biased but I would use always the master, but I am not building products that use Zephyr. So it really depends what are your goals and how you are using Zephyr.

[vla3913]

Thanks, I just updated the code to be compliant with 2.3rc1 (although I have seen some items which will need a little additional cleanup). Non regression tests ok on omx1064 with this new version.

[vla3913]

I have difficulties with qemu x86 entropy pool for mbedtls. Do you know who I can contact on the subject ?

[vla3913]

* UDP PubSub is based on multicast UDP. We tried to port it with IPv4 but stopped as this feature doesn't seem to be managed by Zephyr (#2336)

It would not be a big task to create IPv4 join/leave multicast support. Atm I am quite busy with other areas but I can help if someone wants to implement this.
We started working on the subject too and would be happy to help.

[jukkar]

I have difficulties with qemu x86 entropy pool for mbedtls. Do you know who I can contact on the subject ?

@ceolin is probably the best contact here

[vla3913]

@ceolin, is it possible to contact you with some quick questions on the subject ?

[ceolin]

@ceolin, is it possible to contact you with some quick questions on the subject ?

of course :) just let me know how can I help you.

[vla3913]

@ceolin, Hello. I am trying to access hardware entropy device to get entropy for mbedtls. I use this code:

dev = device_get_binding(CONFIG_ENTROPY_NAME);

With CONFIG_ENTROPY_NAME equal to TRNG, it is working fine on imx 1064.
However, I can't get the device on qemu x86. I think that entropy device is not supported on qemu x86 but i don't find the written confirmation. Same question with native_posix and native_posix_64.
Thank you very much for your help.

[ceolin]

@ceolin, Hello. I am trying to access hardware entropy device to get entropy for mbedtls. I use this code:

dev = device_get_binding(CONFIG_ENTROPY_NAME);

With CONFIG_ENTROPY_NAME equal to TRNG, it is working fine on imx 1064.
However, I can't get the device on qemu x86. I think that entropy device is not supported on qemu x86 but i don't find the written confirmation. Same question with native_posix and native_posix_64.
Thank you very much for your help.

We don't have entropy drivers for qemu and native posix. AFAIK qemu can export an entropy source through VIRTIO device but we never implemented a driver for that.

Do you really need access the entropy device ? Can't you use the random subsystem ? we do have CSPRNG and PRNG APIs. You can select the entropy device as backend for the random number generator for productions and use a non-secure version when developing on qemu.

[vla3913]

@ceolin , thanks for your reply. I am going to try to take it into account.

[vla3913]

We have made additional progress. It is now also running on native_posix.
We are now working on the PubSub based on multicast UDP (#2336).
We need to synchronize with the project at this point and see what's next step.
For example, a code review of our porting activity to Zephyr could be a good idea.

[carlescufi]

Before this module is created we need to decide if we want to support both S2OPC and open62541 or just one of them.

[puchm]

In my opinion it would be better to support both. open62541 seems like it needs some more work until it works on Zephyr but S2OPC does not have a free-to-access documentation.

[vla3913]

We have made further progress:
PubSub based on multicast UDP is now working on native_posix and imx_1064.

In order to achieve it, we have modified the multicast UDP Zephyr functions:

• identified one common issue : Multicast emission is only possible for ipv4 starting with 224. #26584
• and suggested a patch for imx1064 IPv4 multicast datagrams can't be received for mimxrt1064_evk board (missing ethernet API) #26585
  Note: this patch is hardware specific and others Ethernet drivers probably need to be adapted too.

We also have added signature and encryption mechanisms on PubSub exchanges.
Doing so, we encountered one issue we reported:
#26435

[jukkar]

* UDP PubSub is based on multicast UDP. This feature doesn't seem to be managed by Zephyr (#2336).

I just saw the Zephyr S2OPC presentation in Zephyr Developer summit, and want to comment that the IPv4 multicast support (IGMP) is now supported in upstream Zephyr 2.6. I hope this helps with S2OPC Zephyr integration.

[carlescufi]

@nashif @MaureenHelm This issue is unrelated to OSDP, and we still need to come to a conclusion on OPC UA,.

[vla3913]

* UDP PubSub is based on multicast UDP. This feature doesn't seem to be managed by Zephyr (#2336).

I just saw the Zephyr S2OPC presentation in Zephyr Developer summit, and want to comment that the IPv4 multicast support (IGMP) is now supported in upstream Zephyr 2.6. I hope this helps with S2OPC Zephyr integration.

Great ! Thanks for you feedback. we are going to try this out.

[vla3913]

New supported boards including:

• stm32h735g_disco
• stm32h747
  see https://gitlab.com/systerel/S2OPC/-/wikis/compilation/compilation_zephyr for guidelines.

[AndreyDodonov-EH]

@vla3913
First of all, thanks a lot for a very relevant enhancemt proposal!

Was there any reason to choose s2opc implementation over open62541 ?

[vla3913]

@AndreyDodonov-EH Thanks !
I think S2OPC and Zephyr share common objectives such as safety and cybersecurity certification so it really make sense to bind the two products.
However, as my team and myself are S2OPC maintainers, my opinion cannot be called truly objective ;-).

[vla3913]

S2OPC is now compliant with Zephyr 3.2.

[zephyrbot]

Hi @jukkar, @rlubos,

This issue, marked as an RFC, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

@vla3913 you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!

[jukkar]

This issue has been open for a long time. @vla3913 are you planning to submit the code to upstream?

[vla3913]

Hello @jukkar,

S2OPC can run on Zephry (see https://gitlab.com/systerel/S2OPC/-/wikis/compilation/Zephyr-compilation) and we maintain it.
When I have created the ticket some time ago, I have tagged it as RFC because I though it can be offered to Zephyr user as an OPC UA module.

[jukkar]

Having it as an outside module is fine and if you have everything working ok, I think we can close this one then.

[vla3913]

Ticket closed as module is external to Zephyr. See https://gitlab.com/systerel/S2OPC/-/wikis/compilation/Zephyr-compilation