Westermo a un fort engagement pour le développement de nos propres solutions de données industrielle, d'où un investissement considérable dans notre département recherche et développement. L'année dernière, 13% de notre chiffre d'affaire a été consacré à la recherche et développement nous permettant ainsi d'avoir de construire de fortes relations avec les principaux fournisseurs de composants et de continuer l'amélioration de notre puissant système d'exploitation WeOS.

Avec la fiabilité si critique dans nos marchés clés, nous avons fortement progressé pour la validation technique de nos produits. Notre WeOS subi des tests automatisés 24/24 h ainsi que des tests de regéression pour vérifier la compatibilité avec nos anciennes plateformes.

Le fait de disposer d'une gamme d'équipements réseau fonctionnant avec le même logiciel, WeOS, et de processus de test uniques développés et réalisés dans les installations de test de la société en Suède donne à Westermo un avantage majeur sur les autres fabricants.

Cela a permis à Westermo de créer une plateforme de test spécifique pour WeOS, qui permet de concentrer toutes les ressources sur ce logiciel. Cette plateforme de test a été développée depuis de nombreuses années et est maintenant utilisée quotidiennement dans le laboratoire de test de logiciels de Westermo. Lorsque des caractéristiques et des fonctionnalités sont ajoutées au logiciel WeOS, de nouveaux tests automatisés sont développés et ceux-ci sont exécutés chaque jour, ce qui se traduit par des millions de tests réalisés.

Les processus de test de logiciels ont été développés pour identifier les éventuels problèmes de qualité, ce qui réduit le risque au minimum absolu de mise sur le marché de logiciels présentant des problèmes de qualité.

Exemple de banc de test

Pour obtenir une authenticité maximale, tous les tests sont effectués sur le produit final configuré comme s'il était installé dans une véritable application client.

Par exemple, le test d'un pare-feu peut porter sur trois produits. Le nœud extérieur (routeur 1) qui essaie de communiquer à travers le pare-feu, le nœud du pare-feu (routeur 2) qui bloque la communication, et le nœud intérieur (routeur 3) qui est protégé. Le cadre de test configurera d'abord les nœuds, puis transférera le contrôle au scénario de test pour exécution.

Dans ce cas de test, il peut y avoir 4 étapes :

• Veiller à ce que le trafic entrant est autorisé vers le réseau interne
• Configurer les règles du pare-feu
• Veiller à ce que le trafic entrant n'atteigne plus le réseau interne
• Nettoyer les ressources utilisées et mettre fin à l'exploitation de manière correct