Conception de micrologiciel intégré

Embedded Motherboard

Embedded Motherboard

En tant que développeur de matériel, nous continuons à étendre notre solution intégrée et à atteindre les objectifs critiques de programmation et de coût du client.

Plus
Thermal Printer

Thermal Printer

Jarltech possède une solide expérience dans le développement d'imprimantes thermiques hautement fiables. Inclut une imprimante thermique de 2 pouces et 3 pouces.

Plus

Plus de 30 ans de développeur et de fabricant de conception de micrologiciels intégrés | Jarltech

Basée à Taiwan, Jarltech International Inc., depuis 1987, fournit la conception de micrologiciels intégrés | intégration de produits électroniques et de matériel pour aider les clients de l'idée au produit réel. Produit principal, y compris la conception de circuits, le développement électronique, l'assemblage de circuits imprimés, la conception industrielle, le développement de matériel, la production à faible volume, le PCB DIP, la solution EMS, la production d'assemblages, la fabrication de circuits imprimés, etc.

Les produits électroniques personnalisés de Jarltech, ainsi que le développement d'ingénierie tels que les conceptions de circuits, de logiciels, de boîtiers et d'échantillons, l'outillage et le moulage, la fabrication industrielle, la certification et les services de marketing sont également fournis. Idée + Design + Production + Service = Jarltech.

Jarltech offre à ses clients un système de point de vente et des périphériques de haute qualité, à la fois avec de solides connaissances en ingénierie et 29 ans d'expérience, Jarltech s'assure que les demandes de chaque client sont satisfaites.

Conception de micrologiciel intégré

Proposer des tests du système vérifient que le produit dépasse les exigences énoncées

Conception de micrologiciel intégré
Conception de micrologiciel intégré

La conception de micrologiciel intégrée qui offre des tests système vérifie que le produit dépasse les exigences énoncées

Nous concevons le firmware en cinq étapes

Au cours des dernières années, nous avons passé beaucoup de temps à consulter et à former les équipes de développement de logiciels et avons déjà développé le micrologiciel au sein de produits ou de familles de produits durables à succès. Bien qu'apprendre à créer une architecture de micrologiciel solide et à restructurer simultanément les logiciels hérités puisse prendre des mois de travail acharné, cinq étapes clés sont facilement identifiables.Nous utilisons ce processus étape par étape pour aider notre équipe à démarrer du bon pied.

Étape 1: Identifiez les exigences

Avant de pouvoir commencer à concevoir un système embarqué ou son firmware, nous devons avoir des exigences claires. Des exigences correctement écrites définissent le QUOI d'un produit. QUE fait le produit pour l'utilisateur, et notez qu'une exigence correctement écrite est silencieuse sur la façon dont cette partie particulière de ce qui doit être réalisé dans son ensemble.

Chaque énoncé d'exigence doit également être deux autres choses: sans ambiguïté et testable. Une déclaration sans ambiguïté ne nécessite aucune explication supplémentaire. C'est aussi clair et concis que possible. La testabilité est la clé. Si une exigence est écrite correctement, un ensemble de tests peut être facilement construit pour vérifier que l'exigence est satisfaite. Un ensemble approprié d'exigences est une liste écrite d'énoncés dont chacun contient la phrase clé "le [produit] devrait ..." et ne dit pas comment il est mis en œuvre, sans ambiguïté et testable. Ainsi, une bonne architecture dépend de bonnes exigences.

Étape 2: Distinguer l'architecture du design

Au fil des ans, nous avons constaté que de nombreux ingénieurs (ainsi que leurs responsables) ont du mal à séparer les différents éléments ou couches d'ingénierie du micrologiciel. L'architecture d'un système est la couche la plus externe du HOW. L'architecture décrit les fonctionnalités persistantes; L'architecture est difficile à changer et doit être adaptée en réfléchissant soigneusement aux utilisations prévues et autorisées du produit.

La conception d'un système est la couche intermédiaire de COMMENT. L'architecture n'inclut pas les noms de fonction ou de variable. Un document de conception de micrologiciel identifie ces détails fins, tels que les noms et les responsabilités des tâches au sein des sous-systèmes ou pilotes de périphérique spécifiques, la marque de RTOS (le cas échéant) et les détails des interfaces entre les sous-systèmes.

Une implémentation est la couche la plus basse de HOW. Si les interfaces sont suffisamment définies au niveau de conception ci-dessus, les ingénieurs individuels peuvent commencer la mise en œuvre des différents composants en parallèle. L'importance de ces éléments difficiles varie quelque peu d'un secteur à l'autre, mais se concentre toujours sur trois grands défis qui doivent être négociés les uns contre les autres: le respect des délais en temps réel, les tests et la gestion de la diversité. La résolution de ces problèmes comprend les trois dernières étapes.

Étape 3: Gérez le temps

Certaines exigences du produit mentionneront des délais explicites. La plupart des produits présentent un mélange d'exigences en temps non réel, en temps réel doux et en temps réel dur. Les délais souples sont généralement les plus difficiles à définir, à tester et à mettre en œuvre sans ambiguïté. Avec les délais identifiés, la première étape de l'architecture consiste à pousser autant d'exigences de rapidité que possible hors du logiciel et sur le matériel.

Séparer la fonctionnalité en temps réel de la majeure partie du logiciel est utile pour deux raisons importantes; d'abord, car cela simplifie la conception et la mise en œuvre du logiciel non temps réel. Avec les exigences de rapidité conçues à partir de la majeure partie du logiciel, le code écrit par des développeurs novices peut être utilisé sans affecter la sécurité de l'utilisateur. Le deuxième avantage de conserver la fonctionnalité en temps réel ensemble est qu'il simplifie l'analyse impliquée pour prouver que tous les délais sont toujours respectés.

Étape 4: Conception pour le test

Chaque système embarqué doit être testé. En général, il est également utile ou obligatoire que les tests soient effectués à plusieurs niveaux. Les niveaux de test les plus courants sont les suivants:
1. Les tests du système vérifient que le produit dans son ensemble satisfait ou dépasse les exigences énoncées. Les tests système sont généralement mieux développés en dehors du département d'ingénierie, bien qu'ils puissent s'intégrer dans un faisceau de test développé par des ingénieurs.
2. Les tests d'intégration vérifient qu'un sous-ensemble des sous-systèmes identifiés dans les diagrammes d'architecture interagissent comme prévu et produisent des résultats raisonnables. Les tests d'intégration sont généralement mieux développés par un groupe de test ou une personne au sein du génie logiciel.
3. Les tests unitaires vérifient que les composants logiciels individuels identifiés au niveau de conception intermédiaire fonctionnent comme l'attendent leurs exécutants. C'est-à-dire qu'ils testent au niveau de l'API publique (Application Programming Interface) que le composant présente aux autres composants. Les tests unitaires sont généralement mieux développés par les mêmes personnes qui écrivent le code testé.

Des trois, les tests de système sont les plus faciles à développer et, bien sûr, un faisceau de test peut devoir être développé pour des tests d'ingénierie et / ou d'acceptation en usine. Mais cela reste généralement plus facile que l'intégration et les tests unitaires, qui exigent une visibilité supplémentaire à l'intérieur de l'appareil pendant son fonctionnement. Pour faciliter le développement, l'utilisation et la maintenance de l'intégration et des tests unitaires, il est important de concevoir le micrologiciel de manière compatible avec un cadre de test logiciel. La meilleure façon de procéder consiste à concevoir les interactions entre tous les composants logiciels aux niveaux que vous souhaitez tester.

Étape 5: Planifiez le changement

La principale considération au cours de la phase d'architecture du micrologiciel du projet est la gestion de la diversité des fonctionnalités et des personnalisations de produits. Pour planifier le changement, vous devez d'abord comprendre les types de changements qui se produisent dans votre produit spécifique. Ensuite, concevez le micrologiciel pour que ces types de modifications soient les plus faciles à effectuer. Si le logiciel est bien conçu, la diversité des fonctionnalités peut être gérée via une seule version de logiciel avec des commutateurs de comportement au moment de la compilation et / ou de l'exécution dans le micrologiciel. De même, de nouvelles fonctionnalités peuvent être ajoutées facilement à une bonne architecture sans interrompre la fonctionnalité du produit existant.


Communiqué de presse