Un serveur web embarqué est un serveur web destiné à être mis en fonction sur un système embarqué et permettant de consulter et d'agir sur ce dernier comme sur n'importe quel élément du web.
De tels serveurs peuvent ainsi prendre place dans des équipements de domotique tels que des matériels électro-ménagers, ou Hi-Fi par exemple, afin d'en permettre le pilotage depuis un poste informatique. Plus généralement, l'implantation d'un serveur web dans un système embarqué permet un accès simplifié à ce dernier à travers une interface Web. Les serveurs web embarqués sont notamment un prérequis pour la mise en œuvre de protocoles tel que Universal Plug and Play (noté UPnP).
La réalisation de tels serveurs est entravée par de nombreux verrous technologiques. Les systèmes embarqués ont, en général, des capacités limitées afin d'en réduire les coûts de production ou d'en augmenter l'autonomie énergétique. Or les technologies du web, initialement destinées à être opérées sur des serveurs en Rack aux capacités bien plus importantes, n'ont pas été définies pour être utilisées sur ces matériels limités. De là découlent les principales spécificités des serveurs web embarqués.
Enjeux
Les serveurs web embarqués sont déjà utilisés pour certaines applications professionnelles. Ils sont par exemple utilisés pour vérifier le fonctionnement ou l'approvisionnement de distributeurs de boissons automatiques. Cependant, le nombre d'applications de la vie courante est limité par le manque d'architecture flexible qui offrirait les performances et les fonctionnalités nécessaires pour intégrer différents capteurs à un prix acceptableKlimchynski, 2006, page 804.
Pourtant, les systèmes connectés au web ont offert de grandes promesses à l'éducation, aux sciences, au commerce et aux clients. Leurs intérêts sont bien connus : Réduction des coûts de réparation et de maintenance grâce à l'accès à distance ; Laboratoires éducatifs virtuels pour l'apprentissage à distance qui permettent des emplois du temps flexibles et de créer de nouvelles opportunités à un coût limité ; Du confort et de la sécurité avec la possibilité de surveiller sa maison à distance ; Surveillance à distance avec une notification en cas de feu, de vol, de situation d'urgence ou de fuite de gaz.
Les SWE sont définis en cinq parties principalesMi-Joung, 2000, page 192 : un serveur HTTP ; une API ; un système de fichiers virtuels ; un module de configuration ; un module de sécurité.
L'enjeu est donc de fournir de tels modules tout en respectant des contraintes de coût, de flexibilité et de performances pour permettre une large diffusion.
Pour implémenter ces parties, le matériel doit contenir un processeur suffisamment puissant et à coût raisonnable, ainsi que de la mémoire flash/EEPROM afin de supporter les interactions entre la pile TCP/IP et l'interface ethernetFilibeli 2007, page 503.
Problématiques
Les problématiques concernant les serveurs embarqués sont très nombreuses. En effet, la taille réduite, la consommation énergétique, l'architecture flexible ainsi que le coût de ces serveurs sont autant de problématiques qu'il est nécessaire de soulever pour amener internet vers les systèmes embarquésZhan, 2008. Cette section va détailler toutes ces problématiques.
Minimisation de l'empreinte mémoire
La minimisation de l'empreinte mémoire est omniprésente dans tous les travaux concernant les serveurs web embarqués.
La RAM, ou mémoire de travail, est à la fois rapide, adressable et accessible en lecture comme en écriture. Elle ne conserve les données que lorsqu’elle est alimentée : on dit qu’elle est volatile. Cependant, elle est très coûteuse (en termes de transistors par bit) et n’est utilisée qu’en quantités limités (typiquement de l’ordre de quelques kilooctets dans le cas des cibles visées)Duquennoy,2009, page 42.
La minimisation de l'empreinte mémoire est une contrainte qui a poussé un laboratoire indien à créer un micro contrôleur 16 bits capable de fonctionner avec seulement 60Ko de mémoire flash et 2Ko de RAMRamakrishnan, 2004, page 189.
Coût d'implémentation Le déploiement à grande échelle du Web des objets nécessite de minimiser le coût unitaire des équipements ciblés. Les évolutions technologiques à venir ne seront pas destinées à l'augmentation des ressources unitaires des équipements, mais à la production en masse de ces équipements.
Une très grande partie des développements de serveurs web embarqués mettent alors l'accent sur cette contrainte de coût et articulent leur travail autour de celle-ci.
Consommation énergétique La consommation énergétique est une problématique omniprésente dans le domaine des systèmes embarqués. En effet, ce type de serveur est destiné à fonctionner en autonomie. Il faut donc que les ressources énergétiques intégrées au système soient suffisamment importantes pour garantir une durée de fonctionnement satisfaisante.
Un exemple est le serveur Small qui a été conçu de manière à minimiser la consommation énergétique ; celui-ci revendique une consommation 40 fois inférieure à celle d'un serveur PC usuel, et ce dans le but de convenir aux exigences d'une utilisation domestiqueMasato Shimano, 2007, page 1.
Taille du support L'utilisation des systèmes embarqués est liée aux applications quotidiennes des foyers, la petite taille du support permet d'intégrer le serveur à n'importe quelle applicationTao Lin, 2004, page 5.
Tao Lin a développé un serveur nommé WebIt de la taille d'une boîte d'allumettes. Il se justifie de la petite taille de son serveur en indiquant que l'intérêt de cette taille réduite est qu'il pourrait être embarqué dans tout type d'équipement, facilement dans une lampe par exempleTao Lin, 2004, page 2.
Cependant, allier fonctionnalités et compacités est un défi extrêmement complexe et les serveurs Web les plus compacts sont par exemple limités à servir des pages statiques de moins d'un segment (paquet)Duquennoy, 2009, page 46.
Flexibilité
Aujourd'hui, une grande part des logiciels embarqués sont encore écrits dans un langage bas niveau (souvent l'assembleur ou le C). La réutilisation du code est presque inexistante, la portabilité est oubliée, et les prérequis en expertise de programmation sont très élevésCourbot, 2010, Introduction.
Dans le but d'améliorer ces facteurs, les environnements d’exécution virtuels dédiés aux systèmes embarqués ont fait leur apparition. Les exemples les plus connus sont des déclinaisons Java tel que J2ME ou JavaCard. Avec une machine virtuelle embarquée, le code des applications peut être exécuté sur n'importe quel périphérique pour lequel la plateforme a été portée. Les programmeurs peuvent s'appuyer sur un haut niveau d'abstraction, et donc ne pas avoir besoin d'être experts sur la plateforme visée.
De plus, ces machines virtuelles fournissent une isolation de l'application et une sécurité au niveau du typage, ce qui est deux points positifs en plus pour la stabilité du serveur.
Performances Les applications Web se sont développées dans un contexte où les accès à Internet étaient de plus en plus rapides et les machines de plus en plus puissantes. Les technologies qui y sont associées sont de plus en plus demandeuses de ressources, du côté des serveurs comme de celui des clientsDuquennoy, 2009, page 43.
Duquennoy, 2009, page 45
À cause de la limitation en ressources des systèmes embarqués, il est important de prendre en compte les performances du serveurWang ZhenXing, 2009, page 208. De ce fait, il est difficile de gérer plusieurs requêtes de différents utilisateurs simultanémentYakun Liu, 2010, page 316. Une des conséquences de cette limitation en ressources est la difficulté à utiliser Java dans le domaine de l'embarqué.
Certains serveurs web embarqués utilisent Jini, mais le plus gros désavantage de ce système est que l’exécution du code Java coûte toujours beaucoup de ressources. En effet, la solution pour faire tourner une machine virtuelle Java (ou JVM) sur un processeur 8-bit est d'utiliser un sous-environnement Java créé spécialement pour l'environnement embarqué. En fonction du processeur, des applications et des composants, un système embarqué classique nécessite environ 40Ko de mémoireFilibeli, 2007, page 504.
Solutions techniques Pour contourner les problématiques abordées dans la partie 2, de nombreuses solutions techniques ont été réalisées.
Avec/sans OS
En fonction des moyens techniques et des finalités du serveur web embarqué, deux choix d'implémentation se détachent. L'une des solutions consiste en l'utilisation d'un système d'exploitation allégé, tandis que l'autre solution consiste en une conception conjointe d'un système d'exploitation et d'un serveur Web.
Avec un OS Dans le cas où l'empreinte mémoire n'est pas une priorité, le choix d'implémentation se tourne vers l'utilisation d'un OS. Cependant, un système d'exploitation "classique" serait nettement trop demandeur de ressources pour être intégré tel quel à un serveur web embarqué. Il existe alors des systèmes d'exploitation plus légers spécialement dédiés aux systèmes embarqués.
C'est le cas de Contiki développé par Adam Dunkels qui ne requiert que peu de ressources pour s'exécuter. Une configuration typique de Contiki ne requiert pas plus de de RAM et de ROM..thumb|TinyOS est un système d'exploitation dédié aux réseaux de capteurs sans fils
Un autre système d'exploitation, TinyOs, a été conçu pour les systèmes fortement contraints et plus spécifiquement pour les réseaux de capteurs sans fils.
Sans OS
L'autre solution, sans OS celle-ci, consiste à concevoir conjointement le système d'exploitation et le serveur Web.
Duquenoy, 2009, page 46
Le serveur SMEWS (Smart and Mobile Embedded Web Server), développé par Simon Duquennoy retient cette dernière solution.
Simplification de la pile TCP/IP L'utilisation de la pile TCP/IP dans des matériels contraints n'est pas évidente. En effet, les protocoles de la couche réseau et transport ont été conçus pour des machines sans fortes contraintes matérielles au cours des années 1980. Ainsi, le code d'une pile IP sur un système comme Linux nécessite plusieurs centaines de kilooctets de mémoire vive. Pourtant, une telle intégration permettrait de pouvoir mettre en commun l'actuel internet et celui des objetsDuquennoy, 2009, page 22.
Cependant, tout le protocole TCP/IP n'est pas nécessaire au bon fonctionnement d'une application internet embarquéeTao Lin, 2004, page 4.
L'une des solutions envisagées pour s'adapter à des matériels fortement contraints consiste alors en l'adaptation de la pile TCP/IP.
Par exemple, Tao Lin, a décidé de simplifier le time-out timer de TCP. L'implémentation standard de TCP utilise un mécanisme complexe (et coûteux en ressources) pour gérer le renvoi de paquets. Dans son implémentation, Tao Lin, lui, considère que si un paquet ne revient pas dans les six secondes, alors il ne reviendra jamais et n'a donc pas besoin d'être envoyé à nouveau. Cela couvre plus de 99 % des cas et permet une économie de ressources relativement importante. Un autre travail, réalisé par Jim Rees, avait aussi soulevé le problème du timer TCP, mais lui avait choisi de ne pas renvoyer de paquets, car selon lui, Rees J., 1999, page 3.
Il existe de nombreuses implémentations de TCP/IP destinées à l'embarqué telles que µC/TCP-IP, openTCP ou encore lwIP. Cependant, elles nécessitent encore plusieurs dizaines de kilooctets de mémoire persistante et s’exécutent pour la plupart au-dessus d'un système d'exploitation. Ainsi d'autres implémentations, encore plus légères ont été développées. Celles-ci sont conçues comme totalement autonome, ne reposent sur aucun système d'exploitation et accèdent directement au matériel.