Serveur web embarqué

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 acceptable^[1].

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^[1].

Les SWE sont définis en cinq parties principales^[2] :

• 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 ethernet^[3].

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és^[4]. Cette section va détailler toutes ces problématiques.

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)^[5].

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 RAM^[6].

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^[5].

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^[1].

« The purpose of this work is to create cost-sensitive, reliable technology that enables Web access to distributed measurement/control systems »^[1]

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 domestique^[7].

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 application^[8].

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 exemple^[9].

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)^[10].

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és^[11].

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^[11].

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^[11].

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 clients^[12].

« Les serveurs du Web des objets, malgré leurs ressources limitées et l'aspect local des réseaux dans lesquels ils évoluent, devront supporter le passage à l'échelle et gérer plusieurs centaines de connexions. En effet, les applications Web nécessitent aujourd'hui que chaque client ouvre plusieurs connexions vers chaque serveur auquel il est connecté, afin de gérer plusieurs requêtes asynchrones simultanées. Un navigateur web tel que Mozilla Firefox ouvre ainsi jusqu'à 15 connexions par serveur. De plus, chaque serveur doit être capable de gérer plusieurs clients, car il peut être inclus dans plusieurs réseaux personnels, voire être accessible depuis Internet. [...] Notons également que l'adoption d'un Web des objets dépend directement du confort d'usage qu'il apporte. Un accès universel à tous les systèmes informatiques environnants n'est attractif que s'il permet des interactions suffisamment réactives. Les serveurs applicatifs du Web des objets devront donc présenter des performances aussi élevées que possible, tout en gérant plusieurs dizaines voire plusieurs centaines de connexions simultanées. »^[13]

À cause de la limitation en ressources des systèmes embarqués, il est important de prendre en compte les performances du serveur^[14]. De ce fait, il est difficile de gérer plusieurs requêtes de différents utilisateurs simultanément^[15]. 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émoire^[16].

Pour contourner les problématiques abordées dans la partie 2, de nombreuses solutions techniques ont été réalisées.

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.

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 2 ko de RAM et 40 ko de ROM^[17].

 

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.

L'autre solution, sans OS celle-ci, consiste à concevoir conjointement le système d'exploitation et le serveur Web.

« Dans ce type d'équipements, une approche utilisant un serveur Web au-dessus d'un système d'exploitation, même temps réel, n'est pas appropriée, car elle ne réduit pas au minimum la consommation de ressources du système. Il est alors nécessaire de s'orienter vers des solutions où le serveur Web et le système d'exploitation sont conçus conjointement. »^[18]

Le serveur SMEWS (Smart and Mobile Embedded Web Server), développé par Simon Duquennoy retient cette dernière solution.

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 objets^[19].

Cependant, tout le protocole TCP/IP n'est pas nécessaire au bon fonctionnement d'une application internet embarquée^[20].

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^[20]. 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, « En pratique, les paquets sont rarement perdus »^[21].

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.

En contrepartie à cette faible empreinte mémoire, leurs fonctionnalités sont réduites au strict minimum^[22]. La plupart d'entre elles ne tolèrent qu'un unique segment non acquitté à chaque instant, ne gèrent pas la congestion du réseau, la remise en ordre des données entrantes, la fragmentation IP et les données urgentes de TCP^[23].

C'est ce qui est le cas du WebCard, un serveur web pour JavaCard. Le serveur ne tient pas compte des paquets qui ne sont pas en destination du port 80 et ignore les options TCP. Il utilise le protocole HTTP 1.0, qui est plus simple et plus facile à implémenter sur le HTTP 1.1. De plus, la méthode GET est la seule supportée. De ce fait, la gestion des paquets fragmentés n'est pas implémenté dans la pile TCP/IP du Webserver. En effet, l'auteur du document suppose qu'une requête GET arrive en un seul paquet non fragmenté^[21].

Poussée à son extrême, la réduction de la pile TCP/IP permet d'obtenir un serveur web véritablement léger. C'est ce qu'a réalisé Adam Dunkels pour MiniWeb, une preuve de concept de l'implémentation minimale d'une pile TCP/IP et d'un serveur web. Cette association utilise utilise entre 24 et 28 octets (en fonction du système pour lequel miniweb est compilé) de RAM pour s’exécuter. Le code (en C) ne comporte que 400 lignes. En contrepartie, ce serveur ne gère qu'une seule connexion à la fois et ne gère pas non plus le contenu dynamique^[24]. Cela dit, Miniweb n'est qu'une preuve de concept, et son application telle quelle n'est pas souhaitable: « It is important to note that this approach of course is totally and utterly wrong; a system using this approach should not be connected to an actual network, let alone the global Internet! »^[24]

 

L'une des solutions retenues pour soulager les serveurs est l’exécution d'une partie du code de l'application du côté du client.

« La technique AJAX présente de bonnes propriétés dans le contexte du Web des objets, où les clients disposent de plus de ressources que les serveurs. Les données dynamiques générées par le serveur sont envoyées sous forme brute, non mise en forme, ce qui allège le trafic et la charge du serveur. Un certain nombre de traitements sont simplement déportés du serveur vers le client. Le support d'applications AJAX constitue ainsi le premier objectif en termes de fonctionnalités pour les applications du Web des objets, car il permet une répartition efficace des charges entre client et serveur. Cet allègement des tâches du serveur permet à ce dernier de mieux passer à l'échelle, servant un plus grand nombre de requêtes et de clients. »^[25] En effet, les traitements effectués par le serveur sont plus rapides, les serveurs peuvent donc traiter plus de requêtes.

 

Le co-design consiste en un développement conjoint de la partie logicielle et de la partie matérielle d'un serveur web embarqué. Les choix de conception de la partie logicielle sont alors établis en fonction de l'architecture matérielle du serveur^[26].

L'architecture matérielle doit être vu comme une variable. Le besoin de conservation énergétique requiert un design complètement différent. Afin d'atteindre les performances visées avec un minimum de ressources, les concepteurs doivent créer une architecture prenant en compte les tâches du processeur. L'environnement Co-design fournit des outils (ordonnanceur, compilateur flexible etc.) pour lier les spécifications systèmes aux architectures matérielles. Différents choix d'algorithmes, de communications entre les blocs matériels/logiciels, et d'allocations mémoires permettent d'atteindre l'équilibre désiré entre la vitesse d'exécution et la consommation énergétique^[26].

Un serveur web embarqué doit normalement utiliser le protocole HTTP pour transmettre des pages Web allant du système embarqué vers l’explorateur web du client et inversement. Les systèmes embarqués ont besoin d'une interface réseau, telle qu'Ethernet, d'une pile de protocole TCP/IP, d'un serveur web embarqué et de pages web statiques et dynamiques^[27].

Le fait que les systèmes embarqués ont des limites en CPU et en mémoire, et que ces ressources sont le plus souvent utilisées par les applications en temps réel, les utilisateurs finaux peuvent percevoir des temps de latence de plusieurs secondes avant que la réponse HTTP leur parvienne^[27]. De plus, les serveurs web doivent être capables de répondre à de multiples requêtes HTTP simultanément, et doivent utiliser le multithreading non bloquant. De cette façon, une transaction en attente de données n’empêchera pas le bon déroulement d'une autre transaction HTTP en cours^[27].

Prenant en compte les considérations matérielles et logicielles évoquées ci-dessus, Filibeli a choisi Ethernut^[28], un projet matériel et logiciel open source pour construire des périphériques Ethernet embarqués. La partie logiciel du projet consiste en l'implémentation d'un RTOS (un OS temps réel), qui supporte la gestion de mémoire dynamique, file d'événement, flux d'entrée/sortie, système de fichiers en flash, et une pile TCP/IP incluant ARP, IP, ICMP, TCP, DHCP, HTTP^[3]. Les serveurs web fonctionnant sur des machines classique avec énormément de périphériques de stockage utilisent le système de fichiers afin de récupérer les documents désirés. Afin d'offrir des fonctionnalités similaire, Ethernut contient un système de fichiers très simple, basé sur les structures de données stockées en mémoire flash^[3].

Dans un souci d'abstraction et de facilitation d'implémentation, les environnements d'exécution virtuels sont mis en avant, tout particulièrement ceux de Java.

Avec le langage Java, les fichiers bytecode doivent être chargés par la machine virtuelle avant de pouvoir être exécutés. Les liaisons doivent être réalisées au plus tard pendant l’exécution, et un bloc statique d'une classe est initialisé par une méthode dédiée, appelée avant la première utilisation de cette classe^[11]. La solution adoptée est de convertir les fichiers bytecode dans leurs formes exécutables, compréhensibles par la machine virtuelle avant de les écrire dans la ROM. Cela permet donc l’exécution de l'application depuis la ROM et de minimiser ainsi l'empreinte mémoire^[11].

J2ME, un framework spécialisé dans les applications mobiles, est un dérivé de Java destiné aux périphériques avec au moins 100Ko de mémoire. Comme ces systèmes embarqués intègrent souvent de la ROM, J2ME met à disposition un outil afin d'utiliser l'avantage de cette mémoire supplémentaire en y pré-chargeant les classes^[29].

JavaCodeCompact (JCC) est la solution de romization J2ME. JCC pré-charge les classes Java dans un format interne à la KVM (Kilobyte Virtual Machine) de J2ME. Cela produit ensuite un fichier C contenant la représentation de ce format interne, qui est compilé et lié avec la machine virtuelle, de telle sorte que celle-ci voit les classes chargées au démarrage. Il est possible d'indiquer à JCC une liste d’éléments inutilisés (champs, méthodes, ...) à enlever, de manière à réduire l'empreinte mémoire du système^[29].

Finalement, JCC permet donc de réduire l'empreinte mémoire d'un système embarqué car il n'y a plus besoin d'embarquer un « class loader ». Les classes sont déjà chargées quand le système démarre. De plus, JCC peut alléger les classes en enlevant certaines parties inutilisées^[29].

Voir Comparaison.

Caractéristiques de quelques exemples de serveurs web embarqués

Année	Nom	microprocesseur	Empreinte RAM	Empreinte Code	Nécessite un système d'exploitation	TCP/IP(v4) (IPv6)	Référence (Logiciel libre  )	Notes
1999	PicoWeb	AVR	512 octets	8 ko	Sans	( )	http://www.picoweb.net/ ( )	Preuve de concept, limitée à 2 pages statiques
2005	MiniWeb	x86 (+ portages)	106 octets[N 1]	4,4 ko[N 1]	FreeBSD, Linux[30]	( )	http://www.sics.se/~adam/miniweb/ ( )	Preuve de concept, limitée à 2 pages statiques
2005	Barracuda	x86, PowerPC, ColdFire, ARM, ...	250 ko[N 2]	code en RAM.	ThreadX/NetX, VxWorks, QNX, Embedded Linux, Windows CE, ...	via le système d'exploitation ( [N 3])	http://barracudaserver.com/ ( )	Serveur d'application embarqué
2005	KLone	x86, PowerPC, ColdFire, ARM, ...	entre 110 ko et 350 ko (avec support SSL)	code en RAM.	Embedded Linux, Windows, MacOSX, uCLinux, BSD, QNX, VxWorks, ...	via le système d'exploitation ( )	http://koanlogic.com/ ( )	Serveur d'application embarqué
2007	Small	32-bit RISC	1,57 Mo[N 4]	?	Real Time T-Kernel	( )	[Shimano] ( )	For home appliances
2008	Contiki web server	AVR, MSP430, ARM, ...	3,3 ko[N 1]	12,3 ko[N 1]	Contiki	( )	http://senstools.gforge.inria.fr/doku.php?id=os:contiki ( )
2009	SMEWS	AVR, MSP430, ARM, x86...	226 o[N 1]	7,7 ko[N 1]	Sans	( )	http://smews.gforge.inria.fr/ ( )	Support d'URL statiques + serveur d'application en C Voir aussi [Duquennoy]

• (en) I. Klimchynski, « Extensible EWS architecture for internet-based data », IEEE sensors Journal, vol. 6, n^o 3,‎ juin 2006
• (en) Nivedita N. Joshi, P. K. Dakhole et P. P. Zode, « Embedded Web Server on Nios II Embedded FPGA Platform, Second International Conference on Emerging Trends in Engineering and Technology », ICETET,‎ 2009
• (en) Lixia Liu, « Embedded Web server system based on SX52 communication controllers », Information Management and Engineering (ICIME),‎ 2010
• (en) Masato Shimano, Futoshi Okazaki, Yoshihiro Saito, Akiya Fukui, Takako Nonaka et Tomohiro Hase, « Small, Embedded Web Server for Home Appliances with Embedded MPU and real-time Operating System », ISCE,‎ 2007
• (en) Wang ZhenXing, Shi LinXiang et Wei ShuTao, « Embedded Web server Architecture For Mobile Phone », International Conference on Future Networks,‎ 2009
• (en) Liu Yakun et Cheng Xiadong, « Embedded Web Server based on arm and Linux », International Conference on Industrial Mechatronics and Automation,‎ 2010
• (en) Tao Lin, Hai Zhao et Jiyong Wang, « Embedded Web Server for equipments, Parallel Architectures, Algorithms and Networks », 7th International Symposium on,‎ 2004
• (en) Zhan Mei-qiong et Ji Chang-peng, « Research and Implementation of Embedded Web Server », International Conference on MultiMedia and Information Technology,‎ 2008
• (en) A. Ramakrishnan, « 16-bit embedded Web server », Sensors for Industry Conference,‎ 2004
• (en) Ju Hong-Taek, Choi Mi-Jung, Han Sehee, Oh Yunjung, Yoon Jeong-Hyuk, Lee Hyojin et J.W. Hong, « An embedded Web server architecture for XML-based network management », Network Operations and Management Symposium,‎ 2002
• (en) M. Can Filibeli, Oznur Ozkasap et M. Reha Civanlar, « Embedded web server-based home appliance networks », Journal of Network and Computer Applications, vol. 30, n^o 2,‎ avril 2007
• (en) Choi Mi-Joung, Ju Hong-Taek, Cha Hyun-Jun, Kim Sook-Hyang et J.W.-K. Hong, « An efficient embedded Web server for Web-based network element management », Network Operations and Management Symposium,‎ 2000
• (en) Masato Shimano, « Small, Embedded Web Server for Home Appliances with Embedded MPU and Real-time Operating System », Consumer Electronics ISCE,‎ 2007
• (en) Alexandre Courbot, Gilles Grimaud et Jean-Jacques Vandewalle, « Efficient off-board deployment and customization of virtual machine-based embedded systems », ACM Transactions on Embedded Computing Systems, vol. 9, n^o 3,‎ février 2010
• (en) Simon Duquennoy, Gilles Grimaud et Jean-Jacques Vandewalle, « TheWeb of Things: interconnecting devices with high usability and performance », 6th IEEE International Conference on Embedded Software and Systems (ICESS'09),‎ mai 2009
• Simon Duquennoy, Smews: un système d'exploitation dédié au support d'applications Web en environnement contraint : Thèse de doctorat, 2009 (lire en ligne)
• (en) Jim Rees et Peter Honeyman, « WebCard: a java card web server », Proceedings of the fourth working conference on smart card research and advanced applications on Smart card research and advanced applications,‎ 1999
• (en) Bill Mark, « Physical/Information Co-Design », Workshop on Software Engineering for Wearable and Pervasive Computing,‎ 2000

• (en) Choi Mi-Joung, Ju Hong-Taek, Cha Hyun-Jun, Kim Sook-Hyang et J.W.-K. Hong, « An efficient embedded Web server for Web-based network element management », Network Operations and Management Symposium,‎ 2000
• (en) Joshi, N.N. Dakhole, P.K. Zode et P.P. Y.C.C.E., « Embedded Web Server on Nios II Embedded FPGA Platform », Emerging Trends in Engineering and Technology,‎ 2009
• (en) Shimano, M. Okazaki, F. Saito, Y. Fukui, A. Nonaka, T. Hase et T. Ryukoku, « Small, Embedded Web Server for Home Appliances with Embedded MPU and Real-time Operating System », Consumer Electronics,‎ 2007
• (en) Gaetano Borriello et Roy Want, « Embedded computation meets the World Wide Web », Communications of the ACM, vol. 43, n^o 5,‎ mai 2000

• Internet des objets
• Serveur Web

•   Portail de l’informatique