search

whitefield-framework / whitefield

Whitefield provides a simulation environment for wireless sensor networks by combining RF simulation provided by NS3 and network stack provided by popular IoT OSes such as Contiki/RIOT/OpenThread.
GNU General Public License v2.0
82 stars 24 forks source link

Integration with https://renode.io/ #104

Open beriberikix opened 4 years ago

beriberikix commented 4 years ago

https://renode.io/ is a device simulation & testing framework that is getting quite popular. Currently it doesn't provide network simulation as part of the project. Would it make sense for whitefield to integrate with Renode?

nyrahul commented 4 years ago

Integration of Whitefield in Renode will be terrific. Currently, Whitefield does not emulate device archs. I had plans to do it for MSP430 in ways similar to Cooja, but Renode is revolutionary in its design.

I have a few questions:

  1. Can renode actually take the target binaries? For e.g., CC2538DK Contiki/RIOT/Zephyr binary and execute on the simulated device on Linux as a process? Renode Github front page indicates so.
  2. Can it also handle network transceivers? Or other add on the base platform?
  3. Is Energy consumption/modeling also handled in renode?

I will try renode with cc2538 in the near future and check how well it works.

Currently, Whitefield supports 802.15.4 interface and integrates well with native mode Contiki/RIOT/Contiki-NG. OpenThread support is not finished. There is a demo-mode Cytoscape env to visualize the network at runtime.

For Whitefield, my plans for 2020 is:

  1. To integrate Power Line Communication interface and Lorawan interfaces.
  2. Using plug-n-play model for binaries. Compile native mode binaries on your host system and upload those to Whitefield.
  3. Support simulation time. Currently, Whitefield operates in real-time hence the experimentation may take long. I have a design to use Whitefield in simulation time such that days/weeks of experimentation could be finished in a few secs/mins.
  4. Use Cytoscape to allow users to design their networks.
  5. Use cloud-based model wherein users could design their network, upload their binaries, get notifications for results and get their experiment results archived.
beriberikix commented 4 years ago

I brought up the idea to @mgielda in the OSS+ELC conference slack - perhaps he can connect you with someone from the team who might be able to answer your questions!

mgielda commented 4 years ago

Great you like Renode and think integration would be a good idea! Adding @PiotrZierhoffer here to elaborate on technical details

PiotrZierhoffer commented 4 years ago

This sounds like a really good idea. At the moment Renode is able to simulate wireless network on a basic level, with configurable signal range and random packet loss, but our focus is mainly on simulating full SoCs and not the communication medium.

To answer your questions: 1 In Renode you can create an environment of one or multiple nodes, possibly connected together over different types of wired and wireless connections. Our goal is to enable running exactly the same software you're able to run on hardware. Apart from having internal connections between nodes, you can connect them to your host machine in different ways - via pseudoterminal, TAP interface and others.

The framework itself runs on Linux, macOS and Windows, with Linux having the best support for host-to-guest connections (which I mention as it's probably something that could be used for integration with Whitefield).

  1. If I understand your question correctly, yes. Renode can simulate the whole SoCs, with all the peripherals. We model them on a behavioral, register level, so that the software perceives our models as real devices. Having said that, we usually focus on peripherals that are interesting for us in use cases we have, mocking or ignoring the ones that are not crucial. You can look at https://github.com/renode/renode/tree/master/platforms/cpus to get a broad idea of what platforms and what peripherals in them we support.

  2. Right now we don't do energy consumption, but it would be possible to estimate it by analyzing interactions with specific peripherals etc. People are asking about these kind of estimations, so maybe in future we'll go that path.

If you have any more questions regarding our modelling, integrations or time flow, please let me know.

CC2538 is definitely a good place to start. We have a 3 node sample setup you can run by calling s @scripts/multi-node/cc2538/rpl-udp.resc in Renode's CLI.

If you open this file you'll find some comments explaining how did we set it up.

nyrahul commented 4 years ago

Thank you @PiotrZierhoffer for the detailed description. This clarifies things for me.

One Q:

rpl-udp.resc, file uses the binary https://dl.antmicro.com/projects/renode/udp-server.elf-s_173732-a2aefb896d521a8fdc2a052cac1933c68cc39bf5 ... I assume that this binary was created using Contiki (ng?), without any modifications to their platforms/drivers code. If this is true, then I can simply substitute my Contiki bins (made for target CC2538dk) in that place? Just confirming. Thanks

PiotrZierhoffer commented 4 years ago

That's correct. I believe it was built from https://github.com/contiki-ng/contiki-ng/tree/develop/examples/rpl-udp (there are Renode scripts in there, although they might be a bit outdated, haven't checked them in a while).

In general yes, your own binary should work. This being said, as Contiki is improved over time, it can use some registers we did not implement at a time we were working at this demo.