Skip to content
This repository has been archived by the owner on Aug 15, 2022. It is now read-only.

Network calculus #11

Open
pavel-kirienko opened this issue Jun 4, 2019 · 0 comments
Open

Network calculus #11

pavel-kirienko opened this issue Jun 4, 2019 · 0 comments
Labels
question Further information is requested

Comments

@pavel-kirienko
Copy link
Member

pavel-kirienko commented Jun 4, 2019

Is anybody aware of any open source real-time network analysis software that is sufficiently generic to be used with at least UAVCAN/CAN and UAVCAN/UDP?

Since UAVCAN aims to support hard real-time safety-critical onboard networks as its main use case, the availability of an adequate planning and analysis tool is paramount. In the very early days of UAVCAN, the protocol definition outlined in the original RFC (which was well before UAVCAN v0, and very different) was validated against a basic networking model of a UAV system using a sophisticated network planning tool vendored by Mentor Graphics (far from open source). The model was defined as a set of node descriptors with publish/subscribe links with expected traffic generated by each publisher along with latency constraints. The model was then preprocessed into a basic CSV file which was then fed into the analysis tool. Those interested will find the source model along with the conversion script and the output CSV in this (very) old archive: bus_csv_gen.tar.gz (you will notice that the CAN frame format looks odd, that's the old v0)

The model allowed us to make the following observations, provided here purely as a demonstration of the idea (this is an excerpt from an email sent by my collaborator at the time, a valuable early contributor to UAVCAN):

I just got the UAVCAN analysis report on the more loaded network. Now this is showing significant problems.

  1. Assuming you have a CAN driver that is working correctly from priority perspective, you will have about 86.68% load and 40 CAN frames that will be potentially overwritten / not getting to the bus in time before a new transmit request arrives.
  2. Assuming you use a generic CAN driver (e.g. one that is in the builtin CAN stack of the LPC24Cxx or in some extent the one in libopencm3, you will have 49 frames overwritten with the same reason. Bus load would be the same.

We should consider providing at least rudimentary support for network modeling in Yukon. The first-order feature is validating the ability of a given network model to meet a set of performance goals such as the worst-case propagation delay per data link and the maximum bandwidth utilization.

Network Calculus: A Comprehensive Guide.pdf

@pavel-kirienko pavel-kirienko added the question Further information is requested label Jun 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant