Conception de logiciels embarqués

11

Je commence dans la programmation de logiciels embarqués à l'aide d'un RTOS et, comme je suis déjà développeur pour des applications bureautiques, je me demandais à quoi ressemble la modélisation de logiciels embarqués à l'aide de diagrammes UML, comme les diagrammes d'activité, les diagrammes de séquence, les cas d'utilisation, etc.

Les logiciels intégrés sont-ils conçus en utilisant UML, de la même manière que les applications de bureau? Est-ce la meilleure option ou y en a-t-il une meilleure? Puis-je avoir quelques exemples?

Existe-t-il un outil spécifique pour cela?

embedded software

— Cassio
source

8

Il n'y a absolument rien de spécifique sur les applications embarquées. Ce qui est spécial, ce sont les applications à ressources limitées , les plus courantes de telles restrictions sont des restrictions de temps, par exemple des exigences en temps réel. Si vous nous en dire plus sur les exigences de votre application, nous pourrions être en mesure de vous donner une réponse spécifique.

— Wouter van Ooijen

3

Je suis totalement d'accord avec les commentaires de @ Wouter sur les applications à ressources limitées, mais je pense qu'il existe des nuances de conception spécifiques associées à l'utilisation d'un RTOS par rapport à un environnement de développement de bureau programmé où les appels bloquants sont une pratique acceptée.

— HikeOnPast

1

Méfiez-vous de la suringénierie des systèmes embarqués. Voir aussi "The King's Toaster" ee.ryerson.ca/~elf/hack/ktoast.html

— drxzcl

2

@drxzcl - Pas d'accord. Tout d'abord, je ne pense pas que vous puissiez faire trop attention lors de la conception de logiciels qualifiés pour l'espace . Deuxièmement, l'approche de l'ingénieur du grille-pain du roi est la raison pour laquelle tant de pain est brûlé. La plupart des grille-pain sont trop simples pour ce qui est en fait un travail non trivial.

— Rocketmagnet

1

@Cassio: Je suis avec Wouter sur celui-ci. Vous devez analyser le problème vous-même, puis cartographier les parties importantes en utilisant le système que vous jugez approprié. Le problème avec le choix d'une représentation avant d'analyser le problème est que vous êtes bloqué en voyant le problème d'une certaine manière. UML est une représentation qui a ses racines dans les logiciels d'entreprise, et vous ne voulez pas vous laisser entraîner dans la conception de logiciels intégrés comme les logiciels d'entreprise.

— drxzcl

8

Il existe des extensions UML en temps réel qui ont été popularisées par une entreprise dont le nom m'échappe pour le moment. Je me souviens d'avoir fait un article là-dessus il y a plusieurs années. Bruce Powell Douglass a écrit quelques livres sur le thème de la modélisation de systèmes embarqués en utilisant UML, mais son entreprise n'est pas celle à laquelle je pense.

Cela dit, pour faire écho à Wouter, les logiciels embarqués n'ont rien de spécial en soi. J'écris tous les jours des logiciels embarqués pour un système qui fonctionne sur des processeurs de classe Pentium; UML est tout à fait applicable. Rappelez-vous également que de nombreux aspects du logiciel de contrôle ont été ajoutés à UML au fil du temps: il existe une syntaxe pour spécifier les événements synchrones ou asynchrones ainsi que le temps de réponse dans les diagrammes de séquence, le comportement du type de réseau Petri peut être trouvé dans les diagrammes d'activité, le comportement du modèle Statecharts encore meilleur que les diagrammes d'état peuvent, etc.

OTOH, beaucoup de gens préfèrent modéliser des logiciels embarqués à l'aide de concepts de conception structurée et de flux de données. Tout dépend du type de système que vous concevez et de ce qui fonctionne le mieux.

— lyndon
source

Merci @lyndon. Mais comment modélisez-vous les logiciels embarqués au quotidien? Pensez-vous que les diagrammes d'activité, les machines d'état et les diagrammes de séquence feraient l'affaire? Je cherche en fait le concept de quoi concevoir, puis quels sont les schémas à faire pour être insérés dans le document de conception, s'il y en a un pour les systèmes embarqués.

— Cassio

Les constructions les plus fréquentes que je vois sont des diagrammes d'état / diagrammes d'état et des diagrammes de séquence pour une utilisation quotidienne. Honnêtement, je pense que nous pourrions utiliser davantage les diagrammes de classe, mais je trouve que les gens ont tendance à créer d'énormes "objets divins". Oh: la société à laquelle je pensais est Artisan Software. Ce lien peut être informatif: werner.yellowcouch.org/Papers/rtuml/index.html#toc7

— lyndon

5

Lorsque nous nous tournons vers un RTOS, nous avons généralement affaire à une application qui a de nombreuses tâches simultanées qui doivent être planifiées de manière optimale afin que chacune d'entre elles respecte ses délais à temps ou partage ses ressources en toute sécurité. Le cadre RTOS que vous choisissez implémente un planificateur de tâches, et votre travail (généralement) consiste à écrire ces tâches individuelles avec un certain ensemble de propriétés (période, priorité, etc.), puis à les remettre au planificateur. Donc, pour la documentation, l'approche que j'adopterais serait de documenter soigneusement chaque tâche.

La plupart des logiciels intégrés et, pour autant que je sache, la plupart des RTOS ne sont pas écrits dans un langage orienté objet et peuvent donc ne pas bénéficier de beaucoup de choses qui sont orientées vers cela comme des diagrammes de classes par exemple.

Cependant, lorsque vous documentez vos tâches RTOS, tout diagramme décrivant bien la tâche serait un grand avantage. J'imagine qu'un diagramme de séquence pour chaque tâche pourrait être très utile par exemple. Parallèlement à cela, vous pouvez spécifier ses exigences strictes telles que sa période / fréquence, sa priorité, toutes les ressources partagées qu'il peut utiliser, les exigences de préemption, etc. machine de son algorithme de programmation.

Prenez n'importe lequel de ces conseils comme vous le souhaitez, je n'ai pas gâché les trucs RTOS depuis mes études, et je n'ai jamais vraiment "documenté" le travail.

— Jon L
source

Merci @JonL. Donc, pour avoir un joli document de conception, j'aurais juste besoin de concevoir les tâches impliquées dans mon application? De plus, je ne suis pas très familier avec un algorithme de planification, je n'ai jamais à m'en occuper. J'utilise RTEMS.

— Cassio

@Cassio, je ne vous dis pas de faire telle ou telle chose, cela dépend vraiment de vous. Essayez simplement de faire ce qui est nécessaire. Si vous n'êtes pas familier avec votre RTOS, je pense que commencer par l'utiliser en premier et comment vous êtes censé l'utiliser serait un bon point de départ. Ensuite, vous pouvez commencer à concevoir vos tâches autour de lui.

— Jon L

Oui, je me familiarise toujours avec les fonctionnalités RTOS. Et merci pour l'approche suggérée! Le fera! Et comme je l'ai déjà dit, je suis nouveau dans les logiciels embarqués, je ne suis pas vraiment sûr de ce qui est nécessaire. Ce serait bien d'avoir une architecture logicielle intégrée ou un document de conception. En auriez-vous un?

— Cassio

"la plupart des RTOS ne sont pas écrits dans un langage orienté objet". Mais pour un cours de modélisation et d'implémentation en temps réel, nous utilisons un RTOS simple (non préemptif) en C ++.

— Wouter van Ooijen

5

La modélisation, c'est avant tout

savoir quel aspect est difficile et complexe dans votre application,
trouver un outil de modélisation / langage / abstraction / convention / notation approprié pour cet aspect
la conception de cet aspect

Par conséquent, aucun outil / approche / etc. de modélisation ne convient à toutes les situations. Un satellite sera probablement un système multitâche en temps réel, probablement avec plus d'un processeur. Les diagrammes de structure des tâches, les MST et les diagrammes de séquence sont probablement utiles (pour n'en nommer que quelques-uns). Si le projet est fait en C, un diagramme de classe est moins susceptible d'être utile (s'il s'avère très utile, le choix de C était probablement faux). Je n'aime pas beaucoup UseCases, et un satellite qui n'a pas d'utilisateur. Les cas d'utilisation sont les plus appropriés dans une situation où vous souhaitez discuter des exigences de votre système avec un utilisateur non technique. Si c'est la situation dans laquelle vous vous trouvez avec un projet satellite, quelque chose a mal tourné.

— Wouter van Ooijen
source

Merci @Wouter. Vous m'avez présenté un nouveau concept: les diagrammes de structure des tâches, sympa! Donc, c'est en C. Que feriez-vous pour un document avec toutes les exigences, sinon UseCases?

— Cassio

OMI, vous avez besoin d'une liste d'exigences identifiables, plus ou moins à usage unique, ne serait-ce que pour baser vos cas de test. Pour moi, les UseCases ne sont qu'une méthode pour accéder à une telle liste. Une bonne méthode, dans certains cas.

— Wouter van Ooijen

1

Je n'ai rien conçu de qualifié pour l'espace. Mais j'ai travaillé pour un sous-traitant aérospatial du ministère de la Défense (DoD) et beaucoup de mes conceptions étaient qualifiées pour le vol. Ils nécessitent beaucoup de documentation sur vos conceptions et fournissent des descriptions d'éléments de données (DID) qui détaillent exactement ce qu'ils veulent voir.

Vous pouvez utiliser la recherche rapide DoD ASSIST pour voir tous les DID des documents qui peuvent être requis si vous tapez "logiciel" dans le champ "Mot (s) dans le titre" et cliquez sur Soumettre. (Je trouve drôle qu'un site DoD lance un avertissement de sécurité de certificat, mais je vous assure que c'est sûr).

Puisque vous posez des questions spécifiques sur un document de conception, voici le SDD ( Software Design Description ). Ils mettent l'accent sur l'utilisation de mots pour décrire chaque partie de la conception. Mais si l'utilisation d'UML, de diagrammes d'état, d'organigrammes, de pseudo-code, etc., peut améliorer la compréhension de la conception, ils aimeraient bien sûr que vous l'incluiez.

La méthode de modélisation que vous choisissez, comme d'autres l'ont indiqué, dépend de votre conception. Mais je pensais que voir un DID pour un logiciel aérospatial pourrait vous aider à écrire votre document de conception car votre projet est lié à l'espace.

— embedded.kyle
source