Une spécification fonctionnelle peut mieux définir la description des exigences d’un système de contrôle ou d’un logiciel en vue de sa réalisation. Imaginez que votre toute nouvelle usine de désalinisation prend jusqu’à quatre heures pour démarrer, et cela si le seul opérateur qui a une compréhension fragmentaire des contrôles est disponible.
Ce qui suit est une histoire vraie : pendant deux semaines, un ingénieur de système nouvellement embauché dans cette entreprise, a passé deux semaines avec les opérateurs pour déterminer comment les contrôles fonctionnaient en faisant des essais et en simulant des erreurs. Ils ont conçu une séquence de démarrage personnalisée, utilisant 20 changements d’écran et des interventions manuelles, pour mettre l’installation en ligne en 20 minutes. Même avec le générateur central en marche, ils n’ont pas fait confiance aux données.
De telles histoires ne sont pas uniques, mais elles n’ont pas à être les vôtres. L’une des meilleures façons de travailler avec un intégrateur de systèmes (IS), après avoir vérifié les qualifications, est de s’assurer que sa portée comprend l’élaboration d’une spécification fonctionnelle claire, cohérente et complète en partenariat avec le propriétaire (l’utilisateur final). Cela signifie qu’il faut définir ce que le système de contrôle doit faire, en termes non équivoques pour le propriétaire, avant de construire quoi que ce soit.
Pourquoi élaborer une spécification fonctionnelle ?
Les systèmes de contrôle ont un impact disproportionné sur les systèmes qu’ils servent. Quelle que soit la qualité de la mise en œuvre des infrastructures et de la conception des processus, un système de contrôle qui fonctionne mal peut entraîner une suite de problèmes, notamment une fiabilité médiocre, une augmentation des coûts, des interventions manuelles, des difficultés de formation, un dépannage prolongé et une capacité réduite à optimiser les opérations.
La résolution de tous les problèmes éventuels
Contrairement à d’autres disciplines du génie industriel, le développement de systèmes de contrôle n’est pas réglementé, et la méthodologie de projet disciplinée n’est pas une pratique courante. Les solutions sont élaborées dans des espaces virtuels où les décisions essentielles peuvent être mises en œuvre sur un coup de tête, où la visibilité des parties prenantes est faible et où la technologie et la terminologie font obstacle à la compréhension des parties prenantes. Imaginez un entrepreneur construisant un réservoir et changeant l’épaisseur de la plaque de fond de moitié au milieu de la construction, sans en avertir personne.
La création d’un nouveau logiciel
L’élaboration d’une spécification fonctionnelle oblige l’IS à concevoir réellement le logiciel (par exemple une IHM, ou Interface homme-machine). Grâce à l’écrit, la structure opérationnelle de votre processus, petit ou grand, peut être rapidement décrite. Mais aussi, elle suit le remplissage des exigences détaillées concernant le comportement et les commandes de chaque séquence : boucle de contrôle, pompe, vanne, interrupteur de sécurité, tendance, alarme, sécurité de l’utilisateur, etc.
Imaginez qu’un propriétaire examine une spécification fonctionnelle de son IS et découvre des défauts ou des omissions fatales. Excellent, ce n’est que du papier, c’est au début du projet, et la spécification fonctionnelle détaillée (SFD) fournit un moyen de communiquer les lacunes à l’IS afin que les changements requis soient mutuellement compris.
En retravaillant les phrases sur papier, l’architecture du système de contrôle peut être optimisée en quelques minutes ou quelques heures. Une alternative habituelle est la “conception au fur et à mesure du code” qui, indépendamment de la compétence perçue du programmeur, produit des structures de programme disjointes qui sont ensuite difficiles à corriger et à développer.
A quoi ressemble une spécification fonctionnelle ?
Un langage simple
Une spécification fonctionnelle doit être rédigée dans un langage simple, décrivant le comportement requis du système dans la terminologie de l’équipement et des processus du propriétaire. Les références à la syntaxe de programmation sont rarement nécessaires. L’accessibilité du document dicte l’efficacité avec laquelle les parties prenantes peuvent fournir un retour d’information lors de la conception, et la manière dont il soutiendra les opérations en tant que matériel de référence. Si un opérateur, un technicien ou un gestionnaire ne peut pas le comprendre, il n’est pas suffisamment bien écrit.
Une structure bien organisée
Une structure de document bien organisée permet au lecteur de mieux comprendre le processus physique, en introduisant les concepts clés et l’intention avant les détails de la stratégie de contrôle.
Une table des matières pourrait se lire comme suit :
- Le contexte du projet
- Les principaux équipements et l’instrumentation
- Les codes de fonctionnement du système
- Les commandes manuelles et les points de consigne pour l’utilisateur
- Le contrôle des processus
- La sécurité
- Les alarmes
- Les tendances
- Les écrans
C’est mieux que rien, les stratégies de contrôle écrites sous forme de diagrammes ou d’organigrammes autonomes laissent d’innombrables lacunes dans les exigences (par exemple : comment les alarmes critiques sont-elles transmises ? Lorsque l’utilisateur appuie sur le bouton “Auto”, quelle séquence se déroule ? Combien de temps les données sont-elles stockées ? Quelles sont les autorisations requises ?). Des spécifications fonctionnelles appropriées constituent la base de la programmation, des tests, du démarrage, de l’acceptation et des opérations. Aussi bien l’IHM que le propriétaire peuvent les utiliser pour mesurer les progrès et la conformité.
Qui rédige une spécification fonctionnelle, et comment le fait-il ?
Idéalement, les IS devraient rédiger la spécification fonctionnelle, car ils sont les plus à même de garantir que les exigences sont bien définies. Toutefois, la valeur la plus élevée est atteinte lorsque les parties prenantes du propriétaire sont engagées dans le processus. Les “ateliers de stratégie de contrôle” sont un format efficace pour faire participer les parties prenantes à la définition des exigences du système de contrôle.
Au cours d’un atelier, l’IS peut discuter et schématiser ce que l’équipement et le processus feront pour encadrer la collecte des exigences en termes pertinents pour les opérations. Il peut ensuite élaborer et soumettre un projet de spécification fonctionnelle et, après approbation, commencer la programmation. Cela peut sembler plus coûteux et plus long, mais les économies réalisées à moyen et à long terme sont considérables. La méthodologie de projet la plus rapide et la moins coûteuse ? Faites-le bien dès la première fois.
Quels sont les avantages de la spécification fonctionnelle ?
Une bonne confirmation du système de contrôle
Une spécification fonctionnelle élaborée de cette manière permet au propriétaire de confirmer le système de contrôle des processus qu’il recevra et lui apporte une valeur ajoutée pendant toute la durée de vie du système. Elle est un document principal offrant des informations claires sur la nécessité de formation, de dépannage, d’optimisation, de nouvelles fonctionnalités, d’expansion du système et de remplacement / rééquipement du système. En l’absence de spécifications fonctionnelles, un SI sera inévitablement engagé pour effectuer une rétro-ingénierie du système existant à un moment donné afin d’aider le propriétaire. Ce coût n’est jamais représenté dans le budget initial du projet.
Un fournisseur de besoin de logiciel
La programmation sans spécification fonctionnelle naît généralement d’un optimisme et d’un manque de conscience communs au développement de logiciels. Les projets exécutés sans cet outil ont tendance à se heurter à des contraintes de budget et de calendrier. Les processus peuvent fournir des nécessités fondamentales aux communautés que les ingénieurs veulent mieux construire, et ils le peuvent.
L’usine de désalinisation de l’introduction est en train de doubler sa capacité, y compris un nouveau système de contrôle. La spécification fonctionnelle a été approuvée et le propriétaire prévoit avec confiance un démarrage entièrement automatisé en 10 minutes, sans changement d’écran.