Pour l'automobile je ne sais pas exactement par contre dans le domaine que je connais les automates industriels les tests sont très poussé et très étonnants.
Déjà la plus part des opérations sont faite en double, voir plus, il intégre des systémes de WatchDog et d'autocontroles très performants qui permettent de déclencher la sécurité cablé en cas de défaillance de l'automate. Apres les automates en questions peuvent fonctionner pendant d'une demis a une seconde sans alimentation, peuvent supporter des variations de tension assez extrémes genre 400V au lieu de 230V ( au pire on grille l'alim mais pas l'automate ) et n'ont donc pas besoin d'onduleur. Ils sont aussi protégés contre les flash UV ( cas d'un court circuit et d'un arc électrique dans l'armoire électrique ) et certains même contre les rayonnements en tous genre ( pour les applications nucléaires ). Je vous épargne les écarts thermique, l'absence de pièce mobile et la résistance aux vibrations.
C'est d'ailleur pour toutes ces raisons qu'un automate motorisé par un processeur a 16Mhz peut avoir un prix exorbitant.
Apres ce qui fait la différence entre un programme automate et un programme évolué, c'est la quasi intégralité du programme automate est réalisé en langage contacte ( ou Ladder ), le graphcet n'étant souvent d'une forme de surcouche ou de macro. Les informaticiens vont s'arracher les cheuveux apprenant cela, le programmateurs de microcontroleurs connaissent surement déjà mais le langage contacte est presque uniquement constitué de combinaison de bit et d'opération logique de base, modélisé de manière a facilité l'apprenticage par des non programmeurs sous la forme de contacte électrique et de fil qui allume une lampe correspondant a une sortie ou un bit.
De la bonne vieille logique booléenne, ou l'on travail bit par bit, ou sur des mots assez court pour faire du comptage. De plus ce mode de programmation est remarquablement adaptés aux systémes temps réel.
On a donc un nombre d'entrée finie et un nombre de sortie finie ( qui dépasse rarement la centaine correspondant généralement aux éntrée et sortie de l'automate ). Il est donc tous a fait possible de tester le programme dans un très grand nombre de configuration. De plus avec un tel mode de programmation une erreur passe rarement inaperçue ( c'est du tous ou rien, et les fonctions a testés ne sont pas innombrable ), et ce que l'on demande avant tous c'est que le systéme ce comporte bien en cas d'erreur ( gestion de la sécurité ).
On a donc un systéme robuste qui effectue des taches simple, mais qui les effectues biens et qui sait gérer les situations de défaillance, alors qu'un programme classique plus complexe ne sera pas en mesure d'apporter autant de sécurité.
[^] # Re: Dans le même esprit....
Posté par Beretta_Vexee . En réponse au journal Vive GNU/linux & Airbus A380. Évalué à 3.
Déjà la plus part des opérations sont faite en double, voir plus, il intégre des systémes de WatchDog et d'autocontroles très performants qui permettent de déclencher la sécurité cablé en cas de défaillance de l'automate. Apres les automates en questions peuvent fonctionner pendant d'une demis a une seconde sans alimentation, peuvent supporter des variations de tension assez extrémes genre 400V au lieu de 230V ( au pire on grille l'alim mais pas l'automate ) et n'ont donc pas besoin d'onduleur. Ils sont aussi protégés contre les flash UV ( cas d'un court circuit et d'un arc électrique dans l'armoire électrique ) et certains même contre les rayonnements en tous genre ( pour les applications nucléaires ). Je vous épargne les écarts thermique, l'absence de pièce mobile et la résistance aux vibrations.
C'est d'ailleur pour toutes ces raisons qu'un automate motorisé par un processeur a 16Mhz peut avoir un prix exorbitant.
Apres ce qui fait la différence entre un programme automate et un programme évolué, c'est la quasi intégralité du programme automate est réalisé en langage contacte ( ou Ladder ), le graphcet n'étant souvent d'une forme de surcouche ou de macro. Les informaticiens vont s'arracher les cheuveux apprenant cela, le programmateurs de microcontroleurs connaissent surement déjà mais le langage contacte est presque uniquement constitué de combinaison de bit et d'opération logique de base, modélisé de manière a facilité l'apprenticage par des non programmeurs sous la forme de contacte électrique et de fil qui allume une lampe correspondant a une sortie ou un bit.
De la bonne vieille logique booléenne, ou l'on travail bit par bit, ou sur des mots assez court pour faire du comptage. De plus ce mode de programmation est remarquablement adaptés aux systémes temps réel.
On a donc un nombre d'entrée finie et un nombre de sortie finie ( qui dépasse rarement la centaine correspondant généralement aux éntrée et sortie de l'automate ). Il est donc tous a fait possible de tester le programme dans un très grand nombre de configuration. De plus avec un tel mode de programmation une erreur passe rarement inaperçue ( c'est du tous ou rien, et les fonctions a testés ne sont pas innombrable ), et ce que l'on demande avant tous c'est que le systéme ce comporte bien en cas d'erreur ( gestion de la sécurité ).
On a donc un systéme robuste qui effectue des taches simple, mais qui les effectues biens et qui sait gérer les situations de défaillance, alors qu'un programme classique plus complexe ne sera pas en mesure d'apporter autant de sécurité.