Vocabulaire

On retiendra pour le périmètre "AUTOMATION" une définition assez large, soient les domaines suivants (principaux ou connexes) :

• instrumentation, mesures et acquisition de données (DAQ)
• contrôle-commande
• couches basses pour de la supervision (orientation SCADA)
• monitoring de process
• couches basses pour du suivi de fabrication (orientation MES)

On vise le développement d'applications propriétaires autonomes et indépendantes (embarquées et/ou débarquées) ; ce n'est pas le (re)développement d'un LabView, d'un InTouch, ou d'un PcVue.

Motivations

Pourquoi réinventer la roue ?

Le principe de Pareto (loi des 80/20) est assez universel ; le développement informatique n'y échappe pas. Pour de nombreux projets d'automation, 80% de l'effort est consacré à des couches de bas niveau, du middleware, de l'infrastructure, des utilitaires. 20% seulement sont dévolus au métier cible de l'application. On peut toujours discuter et émettre des réserves sur la valeur de cette distribution (80/20) mais l'idée est bien là ... et un peu subie.

Tout ce "bas-niveau" et middleware, traitements et mise en forme des données, est en fait très semblable pour de nombreuses problématiques techniques. En outre, ces mêmes problématiques sont très souvent transverses à plusieurs secteurs d'activités.

On pourrait penser au premier abord que certains procédés ou implémentations spécifiques à notre propre projet sont disséminés dans ces couches "communes" ... (si tel est le cas, c'est qu'il y a peut être un problème de conception en amont).

Une vue réconfortante est aussi de considérer que développer tout ceci "en interne", permet/permettrait de conserver la maitrise et sa propriété intellectuelle. Pourtant la place du métier est bien dans l'application [et donc pas dans les couches en question].

C'est "enfoncer une porte ouverte" que de dire que "le développement home-made" ou le (re)développement partiel à chaque projet coûtent très cher. Alors que faire ? externalisation totale, développement offshore ? peut-être, mais dans ce cas, les sujets maitrise, pérennité et propriété intellectuelle doivent être examinés sous un autre angle.

Des solutions existantes

Les solutions suivantes présentent de véritables atouts, mais elles ne sont pas adaptées à tous les projets, toutes les exigences et toutes les contraintes

• les fabricants d'automates programmables ont des solutions verticales et horizontales
• il existe des outils comme LabView de NI, ou TwinCat de Beckhoff
• il existe des frameworks opensource ou commerciaux
• les briques logicielles sont une réalité (et tous cas, c'est une ambition louable)

On peut discuter et pondérer les avantages/inconvénients de chaque artifice présenté ci-dessus, sur leur cout d'acquisition, d'intégration, sur la robustesse, sur la maitrise.

Ce projet s'adresse à des acteurs qui ont déjà établi que les voies précitées n'étaient pas adaptées à leur problématique.

Une autre solution

Aperçu

Un middleware lightweight industriel

L'idée est de développer un middleware générique assurant les grandes fonctions :

• abstraction aux entrées/sorties
• des entités pour la mise en forme et le traitement de données
• un bus d'abstraction aux données (typage, nommage, description, références)
• une logique de contrôle
• des outils de diagnostics et d'infrastructure
• des entités pour la qualification d’évènements et des alarmes
• un moyen simple de scripting pour réaliser des traitements (calculs, traitements conditionnels) et des séquencements

L'abstraction aux entrées/sorties doit assurer le support des communications cycliques synchrones et des communications asynchrones. Cette abstraction doit supporter les protocoles de communication industriels usuels (profibus, canopen, ethercat ... etc) mais aussi des transports plus communs comme des sockets TCP/UDP ou des liaisons séries.

La logique de contrôle doit permettre d'établir des machines à états simples pour piloter des variables métier (produites à partir des entrées et/ou d'autres variables).

La mission principale des entités d'infrastructure est d'offrir la persistance dans une base de données pour des évènements et alarmes.

Limites

Ce middleware, avec par essence une conception assez générique, ne ciblera à priori pas des domaines avec les contraintes suivantes :

• normes de fonctionnement ou de conception non partagées (entre les bénéficiaires)
• redondance et tolérance de pannes (à voir)
• contraintes sécuritaires matérielles et humaines fortes

La gestion des contraintes sécuritaires est de toute façon assurée par "de la logique cablée" ou des systèmes d'exploitation et stack logicielles spécialisés ... donc hors périmètre à priori.

Remarque : de nombreuses applications ont "tout simplement" besoin de robustesse et de fiabilité, avant la déclinaison d'une norme (mais ceci  est un autre débat ...)

Comment

Vue technique

Ce middleware n'a donc pas la vocation de réaliser un LabView like !

Le but est d'avoir un framework portable, suffisamment léger pour être exécutable sur des cibles embarquées (en tout ou partie) avec OS à base de Linux (et probablement FreeRTOS également), et bien évidemment sur un PC (notamment pour la partie IHM) Windows.

Vue projet

La réalisation commerciale de type "boîte noire" d'un tel framework trouvera difficilement son marché dans l'offre actuelle.

La réalisation commerciale de type "boîte blanche" d'un tel framework ? c'est la même remarque. Comment monnayer le travail de nombreux ingénieurs d'application pour assurer une intégration aisée dans des domaines hétérogènes (quand l'offre LabView ne coûte que quelques milliers d'euros). Et c'est sans évoquer les problèmes de mise à disposition de code source.

La réalisation open-source d'un tel framework existe déjà plus ou moins, mais pose immédiatement les caractéristiques et les interrogations traditionnelles de l’open-source : pérennité, licence, cohérence et consistence entre plusieurs composants.

Pourtant, il y a bien une légitimité technique à un tel framework :

• avoir de facto (par design) une isolation entre processus techniques et processus métier (c'est la base ... mais très loin d'être la "norme" dans la réalité).

Pourtant, il y a bien aussi une légitimité économique :

• ne développer qu'une fois les 3/4 du travail (et pouvoir mutualiser ces 3/4)
• adresser les chefs de projet techniques partagés entre utiliser des environnements intrusifs (LabView par ex.) ou tout faire "home made".

Mon idée est que le co-développement d'un tel framework en closed-source, peut réconcilier les apports et les contraintes évoquées.

Une réalisation en co-développement

L'intelligence collective et la mutualisation des ressources (et des couts), c'est la base du co-développement. Mais appliqué ici, on pourrait

• conserver un code source co-réalisé propriétaire, entre partenaires privilégiés (rappelons que le métier de chacun n'est pas et devrait le moins possible être dans le framework)
• on gagne en fiabilité avec des tests d'intégration (de fait) beaucoup plus étendus, car les scénarii et les méthodes sont différents entre chaque application du framework