II.9.2.2.2. Contraintes temps-réel :
Nous avons vu dans le paragraphe précédent,
qu'il y a des cas où les contraintes temporelles pour les
systèmes embarqués prennent la forme de délais qu'il est
impératif de respecter : elles sont appelées contraintes
temps-réel, et, pour pouvoir y répondre, des systèmes dits
« temps-réel » sont nécessaire.
II.9.2.3. Contraintes en mémoire :
Nous avons vu dans le paragraphe II.9.2.1, que dans les
systèmes embarqués, la mémoire disponible pour le code et
pour les données pouvait être limitée. Cette contrainte se
répercute sur le système d'exploitation puisque son code ses
données ajoutés à ceux de l'application doivent pouvoir
tenir dans la mémoire disponible. Il est de plus
préférable de disposer d'un maximum de mémoire pour
l'application ; le système d'exploitation doit donc être le plus
petit possible.
Cette contrainte en mémoire est si forte dans le
domaine des systèmes embarqués, qu'il est fréquent de ne
pouvoir disposer que de quelques kilo-octets de mémoire pour le
système d'exploitation.
II.9.2.4. Les erreurs :
Les systèmes embarqués occupant des fonctions
critiques disposent d'une dernière contrainte : ils ne peuvent pas
être en panne, même en cas d'erreur.
Cette dernière contrainte conduit à des
validations beaucoup plus strictes et donc beaucoup plus longues des
applications embarquées, et aussi des systèmes d'exploitation
embarqués. Des mécanismes de tolérance aux fautes peuvent
aussi être ajoutés au système, ou à l'application,
pour pouvoir continuer à fonctionner malgré les erreurs.
II.9.2.5. L'aspect multiprocesseur
hétérogène :
Les architectures embarquées récentes contiennent
souvent plusieurs processeurs différents, chacun étant
spécialisé pour un domaine : par exemple un processeur
générale pour le contrôle et un
Chapitre II conception des logiciels embarqués
processeur de traitement du signal pour certains calculs. Avec
de telles architectures, l'utilisation d'un système d'exploitation
unique pour gérer l'ensemble des processeurs est problématique :
en effet, une fois compilé pour un processeur, le logiciel ne peut pas
être exécuté sur un autre. Une solution possible est
d'utiliser une machine virtuelle au-dessus des processeurs pour pouvoir
exécuter tout le logiciel dans un langage d'assemblage unique. Cette
solution est peu performante et il est préférable d'envisager une
autre méthode : utiliser un système d'exploitation par
processeur. Cette seconde méthode apporte cependant des contraintes
supplémentaires : tout d'abord les contraintes en surface deviennent
plus fortes, car plusieurs systèmes d'exploitation sont susceptibles de
consommer plus de mémoire qu'un seul ; ensuite il est peut-être
difficile de maintenir une cohérence globale avec plusieurs
systèmes. Enfin, avec une telle architecture, les tâches ne
peuvent pas passer d'un processeur à un autre : il faut décider
avant la compilation de la conception à quel processeur chacune est
allouée.
| 
