search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.49k stars 6.42k forks source link

Add s2opc (OPC UA implementation) module to Zephyr #25046

Closed vla3913 closed 7 months ago

vla3913 commented 4 years ago

Introduction

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

Zephyr and S2OPC have some common points:

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:

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:

Concerns and Unresolved Questions

We have still some unresolved issues including:

Alternatives

N/A

vla3913 commented 4 years ago

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

vla3913 commented 4 years ago

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 commented 4 years ago 
* 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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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

vla3913 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

vla3913 commented 4 years ago 
* 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 commented 4 years ago

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 commented 4 years ago

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

ceolin commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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

vla3913 commented 4 years ago

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 commented 4 years ago

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

puchm commented 4 years ago

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 commented 4 years ago

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:

We also have added signature and encryption mechanisms on PubSub exchanges. Doing so, we encountered one issue we reported: https://github.com/zephyrproject-rtos/zephyr/issues/26435

jukkar commented 3 years ago 
* 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 commented 3 years ago

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

vla3913 commented 3 years ago 
* 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 commented 2 years ago

New supported boards including:

AndreyDodonov-EH commented 2 years ago

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

Was there any reason to choose s2opc implementation over open62541 ?

vla3913 commented 2 years ago

@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 commented 1 year ago

S2OPC is now compliant with Zephyr 3.2.

zephyrbot commented 7 months ago

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 commented 7 months ago

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

vla3913 commented 7 months ago

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 commented 7 months ago

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

vla3913 commented 7 months ago

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