Serveur web embarqué

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.

Sommaire 1 Enjeux 2 Problématiques 2.1 Minimisation de l'empreinte mémoire 2.2 Coût d'implémentation 2.3 Consommation énergétique 2.4 Taille du support 2.5 Flexibilité 2.6 Performances 3 Solutions techniques 3.1 Avec/sans OS 3.1.1 Avec un OS 3.1.2 Sans OS 3.2 Simplification de la pile TCP/IP 3.3 Exécution côté client 3.4 Co-design 3.4.1 Exemple 3.5 Java et les Serveurs Web Embarqué 4 Annexes 4.1 Exemples 5 Notes et références 5.1 Notes 5.2 Références 5.3 Bibliographie 5.4 Bibliographie Annexe 5.5 Articles connexes

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 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].

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és^[4]. 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 kilo-octets 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].

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^[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 enablesWeb access to distributed measurement/control systems"^[1]

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

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

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

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

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

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

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

"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 dont présenter des performances aussi élevées que possible, tout en gérant plusieurs dizaines voire plusieurs centaines de connexions simultanées."^[5]

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

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

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.

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

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

La pile TCP/IP est l'ensemble des protocoles qui constituent la pile de protocoles utilisée pour l'internet.

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 80. Ainsi, le code d'une pile IP sur un système comme Linux nécessite plusieurs centaines de kilo-octets de mémoire vive. Pourtant, une telle intégration permettrait de pouvoir mettre en commun l'actuel internet et celui des objets^[15]. Cependant, tout le protocole TCP/IP n'est pas nécessaire au bon fonctionnement d'une application internet embarquée^[16]. 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^[16].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"^[17].

Il existe de nombreuses implémentations de TCP/IP destinées à l'embarqué telles que µC/TCP-IP ou openTCP. Cependant, elles nécessitent encore plusieurs dizaines de kilo-octets de mémoire persistante et s'éxé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^[18]. 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^[19].

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 methode "GET" est la seule supporté. 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é^[17].

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'éxé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^[20]. 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!"^[20]

Exécution côté client

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."^[5]En effet, les traitements effectués par le serveur sont plus rapides, les serveurs peuvent donc traiter plus de requêtes.

Co-design

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

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é avec un minimum de ressources, les concepteurs doivent créer une architecture prenant en compte les tâches du processeur. L'environnement Co-design fournis des outils (ordonnanceur, compilateur flexible etc.) pour lier les spécifications systèmes aux architectures matérielles. Différent choix d'algorithmes, de communications entre les blocs matériels/logiciels, et d'allocations mémoires permet d'atteindre l'équilibre désiré entre la vitesse d'exécution et la consommation énergétique^[21].

Exemple

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éseaux, tel que Ethernet, d'une pile de protocole TCP/IP, d'un serveur web embarqué et de pages web statiques et dynamiques^[22].

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é 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^[22]. De plus, les serveurs web doivent être capable 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^[22].

Prenant en compte les considérations matérielles et logicielles évoqué ci-dessus, Filibeli à choisi Ethernut^[23], un projet hardware et software open source pour construire des périphériques Ethernet embarqué. 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é/sortie, système de fichier en flash, et une pile TCP/IP inculant 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 fichier afin de récupérer les documents désirés. Afin d'offrir des fonctionnalités similaire, Ethernut contient un système de fichier très simple, basé sur les structures de données stocké en mémoire flash^[3].

Java et les Serveurs Web Embarqué

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

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

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 tel sorte à ce 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^[24].

Au final, 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^[24].

Annexes

Exemples

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

Année	Nom	microprocesseur	Emprunte RAM	Emprunte 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]	Sans	()	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]

Notes et références

Notes

Références

Bibliographie

• (en) I. Klimchynski, « Extensible EWS architecture for internet-based data », dans 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 », dans ICETET, 2009 
• (en) Lixia Liu, « Embedded Web server system based on SX52 communication controllers », dans 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 », dans ISCE, 2007 
• (en) Wang ZhenXing, Shi LinXiang et ShuTao, « Embedded Web server Architecture For Mobile Phone », dans International Conference on Future Networks, 2009 
• (en) Liu Yakun et Cheng Xiadong, « Embedded Web Server based on arm and Linux », dans International Conference on Industrial Mechatronics and Automation, 2010 
• (en) Tao Lin, Hai Zhao, Jiyong Wang, Han et Jindong Wang, « Embedded Web Server for equipments, Parallel Architectures, Algorithms and Networks », dans 7th International Symposium on, 2004 
• (en) Zhan Mei-qiong et Ji Chang-peng, « Research and Implementation of Embedded Web Server », dans International Conference on MultiMedia and Information Technology, 2008 
• (en) A. Ramakrishnan, « 16-bit embedded Web server », dans 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 », dans Network Operations and Management Symposium, 2002 
• (en) M. Can Filibeli, Oznur Ozkasap et M. Reha Civanlar, « Embedded web server-based home appliance networks », dans 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 », dans Network Operations and Management Symposium, 2000 
• (en) Masato Shimano, « Small, Embedded Web Server for Home Appliances with Embedded MPU and Real-time Operating System », dans 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 », dans ACM Transactions on Embedded Computing Systems, vol. 9, n^o 3, février 2010 
• (en) Simon Duquennoy et Gilles Grimaud, « TheWeb of Things: interconnecting devices with high usability and performance », dans 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 », dans 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 », dans Workshop on Software Engineering for Wearable and Pervasive Computing, 2000 

Bibliographie Annexe

• (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 », dans 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 », dans 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 », dans Consumer Electronics, 2007 
• (en) Gaetano Borriello et Roy Want, « Embedded computation meets the World Wide Web », dans Communications of the ACM, vol. 43, n^o 5, mai 2000 

Articles connexes

• Internet des objets
• Serveur Web

• Portail de l’informatique