The simulation of an IoT infrastructure in terms of equipment, service layer and application require calibration of the inputs of the simulator. The different layers of the model proposed in the ETSI TS 103 840 document have an impact on the overall system. The aim of oneM2M-profiler is to propose a measurement architecture making it possible to extract measurements from particular real execution on given equipment, from a particular oneM2M stack for a particular application. Those measurements should be generalized at the simulator level to give KPIs having values as close as possible to the reality of deployment on other equipment for IoT applications with different configuration and behaviour.
## Getting started
## Struture and protocol for the profiler
To make it easy for you to get started with GitLab, here's a list of recommended next steps.
The tool is based on two program one call proler and another one called onM2M query generation client. In the initial state, the profiler is executed on a machine and an onM2M query generation client is launched, then the experimental protocol is started:
1. The query generator begins by asking the profiler to launch and start monitoring a particular oneM2M CSE
2. The CSE is executed on the machine
3. The query generator warns the profiler that it must begin its observation on a particular sequence of queries that it will perform on the CSE
4. The profiler launches its observation
5. The query generator executes a set of queries to the CSE
6. The query generator notifies the profiler that the queries on the CSE have been completed and that it can generate the observation statistics of the hardware resources used by the CSE
7. The profiler saves its observations in a file which will be used as input to the simulator
8. When the entire profiling plan is completed, the query generator asks the profiler to stop the CSE
9. The profiler stops the CSE and terminates
10. The query generator ends
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
## Profiler usage
## Add your files
The installation and configuration process involves both the IoT stack you want to observe, the profiler and the query generator. The first step begins with installing the IoT stack you want to observe on the concerned machine. You must configure it (name of the CSE, address, etc.). Please note that version 1 of query generator only accepts the http protocol.
The second step concerns the installation of the profiler and the query generator to be downloaded from this git. All these programs are written in Python and therefore require the Python interpreter to be installed on the CSE machine and the query generator machine.
The third step concerns the profiler. The profiler program must be put in the directory where the CSE code is located. In version 1 of the profiler only CSEs from the ACME and OM2M distributions are created. Three parameters must be configured in the profiler: the HOST variable specifying the IP address of the profiler, the PORT specifying the port which will be used to communicate with the profiler and the MIPS (million instructions per second) constant for the processor processing capacity in term of MIPS.
The fourth step concerns the configuration of the query generator. The connection with the profiler must be made through the HOST and PORT variables of the generator which must have the same values as the HOST and PORT variables of the profiler. Then you must configure the information concerning the IoT stack through the variables CSE_URL_XXX and ORIGIN_XXX (XXX is to be replaced by the correct IoT stack name) which gives respectively the URL of the CSE and the authentication necessary for connection.
Finally, the last step of configuration concerns the connection with an http server in the case of using the notification mechanism via the HTTTP_SERVEUR variable. For example, the ACME notification server can be used.
-[ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
-[ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:
## Getting started
The first step is to run the profiler via the command: "python3 profiler.py"
The second step is to run the query generator. Two modes exist:
- Interactive mode: in this mode an interaction with the user allows you to choose the IoT stack, the type of resource, the number of operations to be done on the same type of resources in order to generate averages;
- Automatic mode: in this mode a pre-defined scenario allows you to create and destroy the most classic oneM2M resources by choosing the stack to execute and the number of requests per resource to generate the statistic.
```
python3 oneM2M_Ressources.py auto [OM2M/ACME/MOBIUS] [number of iterations per test]"
```
These two executions generate in the directory where the profiler is located and on its machine a file with the statistics indexed by the name of the stack.
## Integrate with your tools
-[ ] [Set up project integrations](https://labs.etsi.org/rep/iot/smartm2m-onem2m-performance-evaluation/onem2m-profiler/-/settings/integrations)
## Collaborate with your team
-[ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
-[ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
-[ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
-[ ] [Automatically merge when pipeline succeeds](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html)
## Test and Deploy
Use the built-in continuous integration in GitLab.
-[ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html)
-[ ] [Analyze your code for known vulnerabilities with Static Application Security Testing(SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
-[ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
-[ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
-[ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
***
# Editing this README
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thank you to [makeareadme.com](https://www.makeareadme.com/) for this template.
## Suggestions for a good README
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
## Name
Choose a self-explaining name for your project.
## Description
Let people know what your project can do specifically. Provide context and add a link to any reference visitors might be unfamiliar with. A list of Features or a Background subsection can also be added here. If there are alternatives to your project, this is a good place to list differentiating factors.
## Badges
On some READMEs, you may see small images that convey metadata, such as whether or not all the tests are passing for the project. You can use Shields to add some to your README. Many services also have instructions for adding a badge.
## Visuals
Depending on what you are making, it can be a good idea to include screenshots or even a video (you'll frequently see GIFs rather than actual videos). Tools like ttygif can help, but check out Asciinema for a more sophisticated method.
## Installation
Within a particular ecosystem, there may be a common way of installing things, such as using Yarn, NuGet, or Homebrew. However, consider the possibility that whoever is reading your README is a novice and would like more guidance. Listing specific steps helps remove ambiguity and gets people to using your project as quickly as possible. If it only runs in a specific context like a particular programming language version or operating system or has dependencies that have to be installed manually, also add a Requirements subsection.
## Usage
Use examples liberally, and show the expected output if you can. It's helpful to have inline the smallest example of usage that you can demonstrate, while providing links to more sophisticated examples if they are too long to reasonably include in the README.
## Support
Tell people where they can go to for help. It can be any combination of an issue tracker, a chat room, an email address, etc.
## Roadmap
If you have ideas for releases in the future, it is a good idea to list them in the README.
## Contributing
State if you are open to contributions and what your requirements are for accepting them.
For people who want to make changes to your project, it's helpful to have some documentation on how to get started. Perhaps there is a script that they should run or some environment variables that they need to set. Make these steps explicit. These instructions could also be useful to your future self.
## Profiler output format
You can also document commands to lint the code or run tests. These steps help to ensure high code quality and reduce the likelihood that the changes inadvertently break something. Having instructions for running tests is especially helpful if it requires external setup, such as starting a Selenium server for testing in a browser.
The profiler generates a text file. The format of this text file is:
- a first line gives an information on performance of the machine with indication of MIPS;
- all other lines have the format: type of oneM2M resources, type of action and a list of hardware type and value measured.
## Authors and acknowledgment
Show your appreciation to those who have contributed to the project.
The first list of hardware resource on this first version is:
- cpu: average time of processors usage in second;
If you have run out of energy or time for your project, put a note at the top of the README saying that development has slowed down or stopped completely. Someone may choose to fork your project or volunteer to step in as a maintainer or owner, allowing your project to keep going. You can also make an explicit request for maintainers.
