Compare commits

...

3 commits

Author SHA1 Message Date
4f2f24fe7e concept 2024-03-10 21:36:48 +01:00
a9e60a9ba0 iot tp1 2024-03-10 21:35:34 +01:00
22eb5c7ad3 surete init 2024-03-10 21:34:54 +01:00
14 changed files with 429 additions and 0 deletions

239
concept/01_init.md Normal file
View file

@ -0,0 +1,239 @@
# Conception et architecture
## Introduction
Phase de conception : processus créatif de décision des roles, relation et interfaçage entre les composants d'un système.
### Modélisation
- Support de conception.
- Formalisation de la solution.
Réduit la complexité du système :
- met en évidence les détails superflu, pour les éliminer.
- met en évidence les caractéristiques importantes à prioriser.
Création d'un modèle :
- abstrait, non implémenté et dense en concepts
- concu en vue de décrire le système pour son implémentation et ses possible évolutions
Le modèle sert :
- de document d'échange entre clients et développeurs
- d'outil de conception
- de référence, pour le développement, l'extension et la maintenance
### Documentation
Une possibilité : des textes de spécification :
- en langage naturel
- ambigu
Document de spécification :
- en langage spécifique au domaine
- supposé exaustif
Langages à différents niveaux de formalisastions.
- langages formels : s'appuient sur les mathématiques, permet des prouver des propriétés des spécifications.
- langages semi-formels : s'appuient sur les caractéristiques techniques de l'implémentation, suppose une expertise chez le lecteur car il en est le vérificateur.
Langages formels :
- précis, analysable.
- maitrise difficile et usage laborieux.
- principalement restreint aux logiciels critiques.
Langages semi-formels :
- suffisant.
- simple à lire et rédiger, peut être graphique.
- décrit le système à plusieurs niveau d'abstractions.
## UML, Introduction générale
Langage
- Syntaxe et règles d'écriture
- Représentations graphiques normalisées
Modélisation
- abstraction du fonctionnement de la structure d'un système
- spécification et description
Unifié
- fusion de plusieurs notations antérieures
- standard défini par l'OMG (Object Management Group)
Historique
- 1.0.0 en 1997
- 2.5.1 en 2017
en 1990
- apparition de la programmation structurée objet, nécessité d'une méthodologie de conception adaptée.
- apparition de nombreuses méthodes
en 1994
- consensus sur trois méthodes
- OMT Object Modeling Technique : représentation graphique
- BOOSH
- OSEE
### Usage
UML est très large en cas d'usage, et d'autres professions s'en servent également.
En programmation, plusieurs modes :
- Mode esquisse
- Diagrammes tracés à la main, de manière incomplète.
- Support de communications abstraites pour concevoir des parties technniques et critiques.
- Mode plan
- diagrammes formels détaillés.
- annotations en langue naturelle.
- Peut être utilisé pour générer des squelettes de codes.
- Mode programmation
- spécification complète et formelle du système.
- Est utilisé pour générer un code fini et directement utilisable.
## Vue fonctionnelle du système
### Vues :
- Cas d'utilisation
- Description du modèle vu par les utilisateurs du système.
- Besoins attendus par chaque acteur.
- Logique
- Définition du système vu de l'intérieur
- décrit à haut niveau comment satisfaire les besoins des acteurs
- Implantation
- Dépendance entre les modules
- Processus
- Vue temporelle
- illustre le comportement dynamique du système
- Déploiement
- Distribution des instances du système
14 types de diagrammes, organisés en hiérarchie
- Diagrammes structurels : Classes, Objets ...
- Diagrammes comportementaux : Cas d'usage, états ...
- Diagrammes d'interactions : Séquence, communications ...
### Spécification :
- Diagrammes de cas d'utilisation
- Illustre les besoins des utilisateurs.
- Diagrammes de séquence
- Scénarios d'intéractions entre le logiciel et l'extérieur.
- Pas de détails sur les différents composants du systèmes.
- Diagrammes d'activité
- Enchainement d'actions représentatn un comportement du logiciel.
### Conceptions :
- Diagrammes de classes : structure interne du logiciel
- Diagrammes d'objet : état interne du logiciel à un instant de l'execution
- Diagrammes de séquences : intéractions entre les objets lors d'une procédure
Briques de bases
- Les éléments :
- Les abstractions essentielles au modèle.
- Les relations :
- Les relations expriment les liens existatnts entre les différents éléments.
- Les diagrammes :
- Représentations visuelles des éléments du systèmes.
- Donnent une vue partielle du système, l'ensemble de ses diagrammes doit donner une vue globale.
## Diagramme de cas d'usage
Pourquoi ?
- permet au client de spécifer ses besoins :
- Parvenir un accord / contrat entre clients et développeurs.
- Point d''entrée pour les étapes suivantes de conception et développement.
Décrit un usage
- USage que les acteurs font du système
- Acteur : Entité extérieure qui interagit avec le système
- Une même personne peut jouer le roles de différents acteurs.
- un acteur peut être une personne ou bien un autre système.
- Généralement composés de plusieurs scénarios
- Scénario de base (cas nominal).
- Et ses variantes (cas particuliers).
Comment découvrir les cas d'usages ?
- délimiter le périmètre du système
- identifier les acteurs interagissant avec le système
- ceux qui utilisent le système
- ceux qui fournissent un service au fonctionnement du système
- identifier les acteurs principaux
- qui utilisera ce système, et pourquoi ?
- définir les cas d'utilisation correpsondant à ces buts
Éléments
- Des acteurs :
- un rôle dans le système
- pas forcément une personne physique
- potentiellement un autre logiciel
- une même personne ou système peut représenter plusieurs acteurs
- principal ou secondaire
- principal : provoque spontanément des échanges
- secondaire : solicité par le système pour remplir son rôle
- Des cas d'utilisations :
- Une procédure qu'un acteur peut déclancher avec le système pour répondre à un besoin.
- Les acteurs impliqués das un cas d'utilisation lui sont liés par une association.
- Unacteur peut utiliser plusieurs fois le même cas d'utilisation.
- Peut être en relation avec d'autres cas d'utilisation :
- Inclusion : A --- includes -> B, 'le cas A inclut le cas B', faire B est une partie de faire A
- Extension : A <-- extends --- B, 'le cas A étends du cas B', faire A peut impliquer de faire B
- Généralisation : A <|------------- B, 'le cas A est une généralisation du cas B', faire B est une manière de faire A
- Les relations indiquent que l'évolution de certains cas d'usages sont susceptible d'avoir un impact sur d'autres.
- Une relation entre deux acteur ne peut être qu'une généralisation.
Description textuelle
- formalisation contractuelle
- composée de
- le nom du cas
- acteurs concernés
- séquence d'actions
- pré conditions
- actions
- post-conditions
- contraintes liées à l'interface homme-machine
- assignation du document (version + date + responsable)
> note :
> En UML, le sens des flèches indique la dépendance d'interface, et non la relation d'inclusion.
>
> c'est à dire : si une flèche va de A vers B
> - A dépends de B
> - une évolution de l'interface de B peut nécessiter une évolution de A.
exemple : extraction d'un cas d'usage depuis une documentation technique.
```
The 12 bit [Analog to digital converter (ADC)] is a successive approximation analog-to-digital converter.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\_ système étudié
It has up to 18 multiplexed channels allowing it measure signals from [16 external] and [two internal] sources.
acteurs externes concerné par l'usage _/^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[A/D conversion of the various channels] can be performed in single, continuous, scan or discontinuous mode.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\_ description d'un usage/service
The result of the ADC is stored in a left-aligned or right-aligned 16 bit data register.
The analog watchdog feature allows the application to detect if the input voltage goes outside the use-defined high or low thresholds.
```
le système : **Analog to digital converter (ADC)**
acteurs : user/application, sources
acteurs (alt) : user/application, sources (genéral), **16 external** sources, **two internal** sources
cas d'usages : **A/D conversion of the various channels**

61
iot/01_init.md Normal file
View file

@ -0,0 +1,61 @@
# Introduction
## Fondements
### M2M (Machine to Machine)
Type de système supposé fonctionner en interfaçant avec d'autres machines plutôt qu'avec un humain ;
Ne nécessitant pas d'interactions humaines après la mise en place et l'allumage.
- Contemporain des années 1990.
- Provoqué par la démocratisation des technologies céllulaires.
- Usage lourd de réseaux :
- Technologies sans fils.
- Réseaux privées.
- Environement fermé autour de la tâche de l'appareil et peu maléable.
### IoT (Internet of Things)
Famille d'objets interconnectés, intégrés dans des applications et capteurs.
- Hérite des principes de M2M.
- Usage des réseaux Internets.
- Accède au réseau publique.
- Usage d'API, de services décentralisés.
- Environement polymorphique, extensible et adaptable.
### Différences
- Permet plus d'analyses et de traitement sur les données.
- Modèle économique : L'utilisateur achète un service ou un abonnement plutôt qu'un produit.
### Principes
- Actionneurs, capteurs, réseau et applications.
- Basé sur des protocoles de communication standardisés pour permettre une inter-opérabilité des appareils.
### Par rapport à un système embarqué
Un système embarqué :
- Objet remplissant une ou plusiuers fonctionnalités aidées par un système informatique et optimisé par une efficacité énergétiique et des ressources limitées.
- Exemples : panneau d'affichage urbain, systèmes de contrôle de véhicules, console de jeux.
## Applications
- Domotique
- Industrie
- Robotisation
- Optimisation
- Agriculture
## Architecture
3 couches :
- Couche perception : capteurs et actionneurs
- Couche réseau : partage des données avec un serveur extérieur qui opèrera un calcul
- Couche application : logiciel client du service
## Challengening
.

2
iot/tp1/.gitignore vendored Normal file
View file

@ -0,0 +1,2 @@
acme-onem2m
venv

0
iot/tp1/main.py Normal file
View file

0
iot/tp1/requirements.txt Normal file
View file

12
iot/tp1/run.sh Executable file
View file

@ -0,0 +1,12 @@
#!/bin/sh
set -e
cd "$(dirname "$(realpath "$0")")"
if ! [ -d acme-onem2m ]
then ./setup.sh
fi
cd acme-onem2m
python3 -m acme

41
iot/tp1/setup.sh Executable file
View file

@ -0,0 +1,41 @@
#!/bin/sh
set -e
cd "$(dirname "$(realpath "$0")")"
rm -fr ./venv
rm -fr acme-onem2m
python -m venv ./venv
source ./venv/bin/activate
git clone https://github.com/ankraft/ACME-oneM2M-CSE.git acme-onem2m
python -m pip install --requirement=./acme-onem2m/requirements.txt
python -m pip install --requirement=./requirements.txt
echo "
[basic.config]
cseType=IN
cseID=id-in
cseName=cse-in
adminID=CAdmin
dataDirectory=\${baseDirectory}
networkInterface=0.0.0.0
cseHost=10.75.69.114
httpPort=8080
logLevel=debug
databaseInMemory=True
consoleTheme=dark
[cse.registration]
; Edit this to add more allowed originators.
allowedCSROriginators=id-in,id-mn,id-asn
[textui]
startWithTUI=false
[cse.operation.requests]
enable=true
[http]
enableUpperTesterEndpoint=true
enableStructureEndpoint=true
" > acme-onem2m/acme.ini

10
iot/tp1/src/part_2/step_a.sh Executable file
View file

@ -0,0 +1,10 @@
#!/bin/sh
curl -X POST \
-H 'X-M2M-Origin:Cmysensor' \
-H 'X-M2M-RI:123' \
-H 'X-M2M-RVI:3' \
-H'Content-Type:application/json;ty=2' \
-H 'Accept:application/json' \
-d '{"m2m:ae": {"rn":"MySensor", "api": "NMysensor", "rr": true, "srv": ["3"]}}' \
http://127.0.0.1:8080/cse-in

10
iot/tp1/src/part_2/step_b.sh Executable file
View file

@ -0,0 +1,10 @@
#!/bin/sh
curl -X POST \
-H 'X-M2M-Origin:Cmysensor' \
-H 'X-M2M-RI:123' \
-H 'X-M2M-RVI:3' \
-H 'Content-Type:application/json;ty=3' \
-H 'Accept:application/json' \
-d '{"m2m:cnt": {"rn":"Container"}}' \
http://127.0.0.1:8080/cse-in/MySensor

10
iot/tp1/src/part_2/step_c.sh Executable file
View file

@ -0,0 +1,10 @@
#!/bin/sh
curl -X POST \
-H 'X-M2M-Origin:Cmysensor' \
-H 'X-M2M-RI:123' \
-H 'X-M2M-RVI:3' \
-H 'Content-Type:application/json;ty=4' \
-H 'Accept:application/json' \
-d '{"m2m:cin": {"cnf": "text/plain:0","con": "{\"unit\": \"celsius\", \"value\": \"22\"}"}}' \
http://localhost:8080/cse-in/MySensor/Container

9
iot/tp1/src/part_2/step_d.sh Executable file
View file

@ -0,0 +1,9 @@
#!/bin/sh
curl -X GET \
-H 'X-M2M-Origin:Cmysensor' \
-H 'X-M2M-RI:123' \
-H 'X-M2M-RVI:3' \
-H 'Content-Type:application/json' \
-H 'Accept:application/json' \
http://localhost:8080/cse-in/MySensor/Container/la

3
iot/tp1/src/part_2/step_e.sh Executable file
View file

@ -0,0 +1,3 @@
#!/bin/sh
curl -X PUT -H 'X-M2M-Origin:Cmysensor' -H 'X-M2M-RI:123' -H 'X-M2M-RVI:3' -H 'Content-Type:application/json' -H 'Accept:application/json' -d '{"m2m:cnt": {"mni": 10}}' http://localhost:8080/cse-in/MySensor/Container

4
iot/tp1/src/part_2/step_f.sh Executable file
View file

@ -0,0 +1,4 @@
#!/bin/sh
set -e
curl -X DELETE -H 'X-M2M-Origin:Cmysensor' -H 'X-M2M-RI:123' -H 'X-M2M-RVI:3' -H 'Content-Type:application/json' -H 'Accept:application/json' http://localhost:8080/cse-in/MySensor/Container

28
iot/tp1/src/part_3/step_a.sh Executable file
View file

@ -0,0 +1,28 @@
#!/bin/sh
set -e
alias log="echo '
[step_a.sh]'"
RN_NAME="CINwithLabel"
log creates container
curl -X POST \
-H 'X-M2M-Origin:Cmysensor' \
-H 'X-M2M-RI:123' \
-H 'X-M2M-RVI:3' \
-H'Content-Type:application/json;ty=2' \
-H 'Accept:application/json' \
-d '{"m2m:ae": {"rn":"'$RN_NAME'", "api": "NMysensor", "rr": true, "srv": ["3"]}}' \
http://127.0.0.1:8080/cse-in
log emit notification
curl -X POST \
-H 'X-M2M-Origin:Cmysensor' \
-H 'X-M2M-RI:123' \
-H 'X-M2M-RVI:3' \
-H 'Content-Type:application/json;ty=4' \
-H 'Accept:application/json' \
-d '{"m2m:cin": {"rn":"CINwithLabel", "lbl": ["tag:temperature"], "cnf": "text/plain:0", "con": "{\"unit\": \"celsius\",\"value\": \"22\"}"}}' \
http://127.0.0.1:8080/cse-in/MySensor/Container