WATS est l'acteur historique de la gestion des données de test en production. Présent depuis 2003, bien implanté dans l'électronique, il convient à de nombreuses équipes. Mais c'est un système fermé construit autour des formats WSJF et WSXF, facturé par client et par serveur, dont les analyses supposent que vous envoyez les données chez lui et les consultez dans sa propre interface.
Si vous évaluez des alternatives, la réponse honnête est qu'il en existe quatre : construire vous-même sur Postgres, utiliser un système de rendement semi-conducteur, utiliser un MES, ou utiliser une plateforme moderne de données de test. Ce guide compare chacune face à WATS, y compris les cas où rester sur WATS est la bonne décision.
Pourquoi les équipes cherchent des alternatives
Les raisons qui reviennent le plus souvent :
| Raison | Détail |
|---|---|
| Licence par client | Le coût suit le nombre de stations, pas la valeur reçue |
| Formats propriétaires | WSJF et WSXF sont spécifiques à WATS ; les convertisseurs sont unidirectionnels en pratique |
| Déploiement centré Windows | Le serveur et les clients supposent un parc Windows |
| Rapports d'abord, API ensuite | Sortir les données par programme est plus difficile que les y faire entrer |
| Itération lente sur le code de test | Les séquences vivent dans une chaîne d'outils séparée du dépôt firmware |
| Maintenance sur site | Administration SQL Server, mises à jour et sauvegardes à votre charge |
Aucun de ces points n'est un défaut. Ce sont les conséquences d'une conception antérieure aux infrastructures cloud-native et aux frameworks de test Python. Si votre atelier est sous Windows et que vos ingénieurs de test n'écrivent pas de code, ils ne vous gêneront peut-être jamais.
Les alternatives
Construire sur Postgres
L'alternative la plus courante, et la première essayée. Un schéma avec unités, runs, étapes et mesures, plus Grafana ou Metabase par-dessus.
Points forts : Contrôle total. Pas de licence. Votre modèle de données correspond exactement à vos produits.
Limitations : Vous maintenez désormais une plateforme de données. La logique de rendement, de Cpk et de cartes de contrôle doit être écrite et validée. La traçabilité des sous-ensembles est plus difficile qu'il n'y paraît. Quelqu'un assume les sauvegardes, les migrations et l'astreinte.
Idéal pour : Les équipes disposant d'un ingénieur données et ayant des besoins inhabituels qu'aucun produit ne couvre.
Systèmes de rendement semi-conducteur
yieldHUB, yieldWerx et similaires sont conçus pour l'analyse de rendement au niveau wafer et die, et y excellent réellement.
Points forts : Analyse approfondie des cartes de wafer, des bins et des paramètres. Natif STDF. Outillage statistique mature.
Limitations : Le modèle de données suppose des wafers, des dies et des bins. Le test fonctionnel au niveau carte avec sous-ensembles sérialisés n'est pas le cas d'usage visé. Tarification à l'échelle entreprise.
Idéal pour : Fondeurs et OSAT, pas l'électronique au niveau carte.
Systèmes d'exécution de production (MES)
Aegis FactoryLogix, Critical Manufacturing et autres MES incluent la capture des données de test comme un module parmi d'autres.
Points forts : Les données de test côtoient le routage, les instructions de travail, les matières et la main-d'œuvre. Un seul système pour toute l'usine.
Limitations : Les analyses de test sont rarement le module le plus fort. L'implémentation se mesure en trimestres, pas en semaines. Le coût reflète le périmètre d'un MES complet.
Idéal pour : Les usines qui ont de toute façon besoin d'un MES.
Plateformes modernes de données de test
TofuPilot se situe ici, comme quelques entrants récents. L'hypothèse de conception : le code de test est en Python, vit dans Git, tourne en CI, et les données doivent être aussi interrogeables par API que consultables dans une interface.
import openhtf as htffrom openhtf.util import unitsfrom tofupilot.openhtf import upload@htf.measures( htf.Measurement("rail_3v3") .in_range(3.2, 3.4) .with_units(units.VOLT),)def power_rail_test(test): test.measurements.rail_3v3 = 3.31def main(): test = htf.Test( power_rail_test, procedure_id="FCT-001", part_number="PCBA-200", ) test.add_output_callbacks(upload()) test.execute(test_start=lambda: input("Scanner le numéro de série : "))if __name__ == "__main__": main()Points forts : Une ligne pour enregistrer un run. Rendement, Cpk, cartes de contrôle et Pareto calculés automatiquement. Le code de test est diffable et relisible. L'auto-hébergement est disponible si les données ne peuvent pas sortir du réseau.
Limitations : Plus jeune que WATS, avec une base installée plus restreinte dans les EMS traditionnels. Si vos ingénieurs de test n'écrivent pas de Python, l'adéquation est moindre.
Idéal pour : Les équipes matériel qui écrivent déjà du Python, utilisent la CI, et veulent des données accessibles depuis un script.
Comparaison des fonctionnalités
| Fonctionnalité | WATS | Postgres maison | Systèmes rendement | MES | TofuPilot |
|---|---|---|---|---|---|
| Déploiement | Sur site ou cloud | Le vôtre | Sur site ou cloud | Sur site | Cloud ou auto-hébergé |
| Licence | Par client et serveur | Gratuit (plus votre temps) | Entreprise | Entreprise | Par station |
| Format de données | WSJF, WSXF | Le vôtre | STDF | Spécifique éditeur | JSON, API REST |
| Framework de test | Client WATS | Tous | Outillage éditeur | Outillage éditeur | OpenHTF, pytest, Robot |
| Rendement et Cpk | Intégrés | À construire | Intégrés (wafer) | Module | Intégrés |
| Cartes de contrôle | Intégrées | À construire | Intégrées | Variable | Intégrées |
| Traçabilité sous-ensembles | Intégrée | À construire | Limitée | Intégrée | Intégrée |
| Accès API | SOAP et REST | SQL direct | API éditeur | API éditeur | REST, Python, C#, Rust |
| Gestion de version des tests | Chaîne séparée | La vôtre | Outillage éditeur | Outillage éditeur | Python natif Git |
| Import depuis WATS | n/a | Manuel | Non | Variable | WSJF et WSXF supportés |
Structure des coûts
Une comparaison directe des prix n'est pas possible : WATS ne publie pas de tarif public et les devis varient selon le nombre de clients, la topologie serveur et la région. Ce qui se compare, c'est la façon dont le coût évolue :
| Modèle | Évolue avec |
|---|---|
| WATS | Nombre de clients et de serveurs |
| Postgres maison | Temps d'ingénierie, indéfiniment |
| Systèmes rendement | Contrat entreprise, souvent par site |
| MES | Périmètre usine complet |
| TofuPilot | Nombre de stations de test |
La question à poser à tout éditeur, WATS inclus : que devient la facture quand vous doublez le nombre de stations, et les analyses sont-elles incluses ou facturées à part ?
Parcours de migration
De WATS vers TofuPilot
L'import WSJF et WSXF est supporté, les données historiques sont donc reprises plutôt qu'abandonnées. L'approche habituelle consiste à faire tourner les deux systèmes en parallèle sur une procédure, confirmer que les rendements correspondent sur les mêmes unités, puis migrer procédure par procédure. Gardez les rapports WATS actifs jusqu'à concordance des chiffres.
De WATS vers Postgres
Exportez via l'API WATS, définissez votre schéma, et reconstruisez les analyses dont vous dépendiez. Budgétez les analyses, pas l'export. Rendement et Cpk sont la partie facile ; la traçabilité des sous-ensembles et les rapports destinés aux opérateurs consomment le temps.
Rester sur WATS
Restez si vos stations sont sous Windows et vos ingénieurs n'écrivent pas de Python, si votre intégration MES ou ERP avec WATS est déjà construite et fonctionne, si vous êtes dans un environnement réglementé où le coût de validation d'un changement dépasse le bénéfice, ou si votre déploiement est stable et que personne ne demande quoi que ce soit qu'il ne fasse pas. « Ça marche et personne ne se plaint » est une raison légitime de ne pas migrer.
Cadre de décision
Choisissez une plateforme moderne si votre code de test est en Python, vous voulez des données accessibles depuis un script, et vous préférez ne pas administrer de base de données.
Construisez sur Postgres si vous avez des besoins inhabituels, un ingénieur données pour en assumer la charge, et une vraie raison qu'aucun produit ne convienne.
Choisissez un système de rendement si vous testez des wafers et des dies plutôt que des cartes et des assemblages.
Choisissez un MES si vous avez besoin de routage, de matières et de suivi de main-d'œuvre, et que les données de test ne sont qu'un besoin parmi d'autres.
Restez sur WATS si ça fonctionne, votre parc est Windows, et le coût du changement ne vous apporte rien dont vous ayez réellement besoin.