Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Koneki/LDT/Technical Discussions/Bandwidth estimation tool specification"
m (→Introduction) |
m (→The user interface of the estimator) |
||
| Line 23: | Line 23: | ||
With the combination of these informations, the estimator will generate abstract data and create a collection of the messages which the device send and receive. Finally, the estimator will use this collection to estimate the bandwidth which the device will consume. | With the combination of these informations, the estimator will generate abstract data and create a collection of the messages which the device send and receive. Finally, the estimator will use this collection to estimate the bandwidth which the device will consume. | ||
| − | = The user | + | = The user interfaces = |
This chapter describes the user interfaces of the tool. By this way, it will by easier to understand how the tool works. The user interface is structured on few pages into three tags. | This chapter describes the user interfaces of the tool. By this way, it will by easier to understand how the tool works. The user interface is structured on few pages into three tags. | ||
| Line 29: | Line 29: | ||
[[Image:Bandwidth estimation tool specification main ui.png]] | [[Image:Bandwidth estimation tool specification main ui.png]] | ||
| − | The first tag is used to edit the scenario of the estimator. | + | The first tag is used to edit the scenario of the estimator. The second tag is used to edit the configuration of all protocols which are available for the estimator. And the third tag is used to show the details of all estimations for each protocols. |
| − | The second tag is used to edit the configuration of all protocols which are available for the estimator. | + | |
| − | And the third tag is used to show the details of all estimations for each protocols. | + | |
| − | The following sections describe the pages of each tags. | + | The following sections describe the pages of each tags. |
== Scenario editor tag == | == Scenario editor tag == | ||
| Line 39: | Line 37: | ||
=== The Data/Events generation page. === | === The Data/Events generation page. === | ||
| − | [[Image:Bandwidth estimation tool specification DataEvents generation.png]] | + | [[Image:Bandwidth estimation tool specification DataEvents generation.png]] |
| − | This page contains the list of all data and events which the device could send during its exploitation. For the estimations, the values of data and events will be automatically generate by the estimator. The bandwidth estimation is based on these artificial values. | + | This page contains the list of all data and events which the device could send during its exploitation. These informations are extract from the application model. For the estimations, the values of data and events will be automatically generate by the estimator. The bandwidth estimation is based on these artificial values. So, for each data and events this page allows to configure how the values are generate. |
| + | |||
| + | For the data, there are five parameters: | ||
| − | |||
*Time unit | *Time unit | ||
| − | *Generation | + | *Generation delay: after this delay, a new value is generate |
*The type of generation: Increment (the values are generate by following increments values), List (the generated values follow one specific list of values), Random (all values are generate with a random method) | *The type of generation: Increment (the values are generate by following increments values), List (the generated values follow one specific list of values), Random (all values are generate with a random method) | ||
*Acquisition delay: after this delay, the last value which have been generated is store to be send later | *Acquisition delay: after this delay, the last value which have been generated is store to be send later | ||
*Publication delay: after this delay, all stored values have to be send by the communication protocol | *Publication delay: after this delay, all stored values have to be send by the communication protocol | ||
| − | + | The event configuration is simpler than data configuration. There are only three parameters. The acquisition delay, the publication delay and the time unit. | |
| − | === The Data/Commands reception page. === | + | The device is also able to receive messages. Below is the details of the Commands/Data reception page. |
| + | |||
| + | === The Data/Commands reception page. === | ||
[[Image:Bandwidth estimation tool specification DataCommands reception.png]] | [[Image:Bandwidth estimation tool specification DataCommands reception.png]] | ||
| Line 58: | Line 59: | ||
The data configuration is the same than for the generation configuration. The command configuration is the same than the events configuration for the generation page. | The data configuration is the same than for the generation configuration. The command configuration is the same than the events configuration for the generation page. | ||
| − | The | + | The following page is use to run some estimations. |
| + | |||
| + | === The bandwidth estimations page === | ||
| + | |||
| + | [[Image:Bandwidth estimation tool specification estimations dashboard.png]] | ||
| + | |||
| + | This is the most important page. It allows to select which protocols will be use during the estimation. The tool offer to select more than one communication protocol. So, in the same time, it's possible to compare different bandwidth of different protocols. | ||
| − | + | The configuration of each communication protocol is settable by cliquing on the button "Edit parameters". The following chapter describes the pages to configure one communication protocol. | |
| − | + | It's in the page that users can choose the period of the estimation and run the estimators. One estimation is run by selected protocols | |
| − | + | Once the estimations are terminate all generate messaged are show into the table "Messages". The detail of the selected message in the table is show into the "Message detail" boxe. | |
| − | + | The statiscs of each estimations are show into the abstract boxes. The number of messages which are send and receive by the device. And the total bandwidth which is consume. | |
| − | == | + | == Protocols configuration tag == |
| − | + | Protocols configuration pages are specific for each protocols which are available for the estimator. Below is one example of the MQTT protocol configuration. | |
=== MQTT configuration page === | === MQTT configuration page === | ||
| Line 78: | Line 85: | ||
'''Qos level''' | '''Qos level''' | ||
| − | For each type of information (data | + | For each type of information (data, events and commands) the configuration page provide to chose which QOS is associate. |
'''Connection parameters''' | '''Connection parameters''' | ||
| − | It's the classical fields to set the connexion settings. | + | It's the classical fields to set the connexion settings. With the ability to set the message which is eventually send after the disconnection.<br> |
'''Serializer name''' | '''Serializer name''' | ||
| − | For each type of information (data | + | For each type of information (data, events and commands) the configuration page provide to chose which serializer is associate. This feature provides to set how the payload is serialize for each MQTT messages. For example, the users could choose a JSON serializer for the data and one binary serializer for the events. |
'''Data/Commands/Events messages pattern''' | '''Data/Commands/Events messages pattern''' | ||
| − | There are many ways to transform the informations (data/commands/events) in MQTT messages. So the configuration page offer to choose which pattern is the best for the application. The patterns offer to broadcast a lot of little messages or few huge messages. For example, the event pattern "asset/events" each messages will contains all events with their name, code and type. | + | There are many ways to transform the informations (data/commands/events) in MQTT messages. So the configuration page offer to choose which pattern is the best for the application. The patterns offer to broadcast a lot of little messages or few huge messages. For example, with the event pattern "asset/events" each messages will contains all events with their name, code and type. If there are lots of events, messages could become very huge. whereas with the pattern "asset/events/name" messages will only contains only the code and the type for one event. But the number of broadcast messages will increase. The use have to chose the best pattern for its application. |
| − | '''The last box "others"''' | + | '''The last box "others"''' |
In this box users can set if they want to broadcast the MQTT subscribe messages before receive new informations. They are also able to configure the date format and intial value. | In this box users can set if they want to broadcast the MQTT subscribe messages before receive new informations. They are also able to configure the date format and intial value. | ||
Revision as of 04:54, 27 March 2012
Contents
Introduction
This document describes the specifications of a generic bandwidth estimator. This tool estimate the bandwidth which is use by one device with different communication protocols during one specified period. So, this tool provides to set three informations.
- The behaviour of the device: which data are send and received
- The communication protocol that the device use
- The period of the estimation
Different combinations of these informations will change the bandwidth used by the device. The estimator is generic because it allows to choose which communication protocol is used by the device.
The following chapters describe:
- A general explication of how the estimator works
- The user interfaces
- The model which is used to describe data
- The model which is used by the estimator
- The architecture which provide to add new protocols for the estimator
How the estimator works
The estimator needs four informations to create one estimation:
- The description of the device: which data the device will send and receive. These informations are already set into the application model.
- How this data will be use by the device: when the device will send and receive informations. These informations are set with the estimation tool.
- Which communication protocol the device will use during its exploitation. This information is also set with the estimation tool.
- The period of the estimation.
With the combination of these informations, the estimator will generate abstract data and create a collection of the messages which the device send and receive. Finally, the estimator will use this collection to estimate the bandwidth which the device will consume.
The user interfaces
This chapter describes the user interfaces of the tool. By this way, it will by easier to understand how the tool works. The user interface is structured on few pages into three tags.
The first tag is used to edit the scenario of the estimator. The second tag is used to edit the configuration of all protocols which are available for the estimator. And the third tag is used to show the details of all estimations for each protocols.
The following sections describe the pages of each tags.
Scenario editor tag
The Data/Events generation page.
This page contains the list of all data and events which the device could send during its exploitation. These informations are extract from the application model. For the estimations, the values of data and events will be automatically generate by the estimator. The bandwidth estimation is based on these artificial values. So, for each data and events this page allows to configure how the values are generate.
For the data, there are five parameters:
- Time unit
- Generation delay: after this delay, a new value is generate
- The type of generation: Increment (the values are generate by following increments values), List (the generated values follow one specific list of values), Random (all values are generate with a random method)
- Acquisition delay: after this delay, the last value which have been generated is store to be send later
- Publication delay: after this delay, all stored values have to be send by the communication protocol
The event configuration is simpler than data configuration. There are only three parameters. The acquisition delay, the publication delay and the time unit.
The device is also able to receive messages. Below is the details of the Commands/Data reception page.
The Data/Commands reception page.
The data configuration is the same than for the generation configuration. The command configuration is the same than the events configuration for the generation page.
The following page is use to run some estimations.
The bandwidth estimations page
This is the most important page. It allows to select which protocols will be use during the estimation. The tool offer to select more than one communication protocol. So, in the same time, it's possible to compare different bandwidth of different protocols.
The configuration of each communication protocol is settable by cliquing on the button "Edit parameters". The following chapter describes the pages to configure one communication protocol.
It's in the page that users can choose the period of the estimation and run the estimators. One estimation is run by selected protocols
Once the estimations are terminate all generate messaged are show into the table "Messages". The detail of the selected message in the table is show into the "Message detail" boxe.
The statiscs of each estimations are show into the abstract boxes. The number of messages which are send and receive by the device. And the total bandwidth which is consume.
Protocols configuration tag
Protocols configuration pages are specific for each protocols which are available for the estimator. Below is one example of the MQTT protocol configuration.
MQTT configuration page
Qos level
For each type of information (data, events and commands) the configuration page provide to chose which QOS is associate.
Connection parameters
It's the classical fields to set the connexion settings. With the ability to set the message which is eventually send after the disconnection.
Serializer name
For each type of information (data, events and commands) the configuration page provide to chose which serializer is associate. This feature provides to set how the payload is serialize for each MQTT messages. For example, the users could choose a JSON serializer for the data and one binary serializer for the events.
Data/Commands/Events messages pattern
There are many ways to transform the informations (data/commands/events) in MQTT messages. So the configuration page offer to choose which pattern is the best for the application. The patterns offer to broadcast a lot of little messages or few huge messages. For example, with the event pattern "asset/events" each messages will contains all events with their name, code and type. If there are lots of events, messages could become very huge. whereas with the pattern "asset/events/name" messages will only contains only the code and the type for one event. But the number of broadcast messages will increase. The use have to chose the best pattern for its application.
The last box "others"
In this box users can set if they want to broadcast the MQTT subscribe messages before receive new informations. They are also able to configure the date format and intial value.