B Kamsu-Foguem
email: bernard.kamsu-foguem@ema.fr

- V Chapurlat

- F Prunet
email: prunet@lirmm.fr

Vérification de modèles de processus d'entreprise : une approche formelle

Keywords: Modélisation d'entreprise, Vérification, Validation, Approche Formelle, Graphes conceptuels, Ontologie Enterprise Modeling, Verification, Validation, Formal Methods, Conceptual Graphs, Ontology

Dans le cycle de vie de développement d'un système industriel, les phases de vérification et, si possible de validation, impactent notablement sur la qualité du système final c'est à dire son adéquation et sa pertinence vis-à-vis de ses objectifs cibles. Dans le domaine de la Modélisation d'Entreprise, il existe peu d'outils de vérification et/ou de validation basés sur d'autres approches que la simulation. Cet article présente une approche formelle pour la vérification des modèles de processus d'entreprise par preuve de propriétés. Cette démarche s'appuie tout d'abord sur la construction d'une ontologie du domaine concerné visant à définir rigoureusement le vocabulaire qui sera utilisé pendant les phases de vérification. Elle met ensuite en oeuvre des mécanismes de traduction et de raisonnement utilisant les graphes conceptuels qui s'avèrent aisés à manipuler dans un milieu industriel.

Une mise en oeuvre de la démarche de vérification proprement dite est enfin proposée afin de démontrer l'intérêt de ce type d'approche dans le domaine.

Introduction

La vérification consiste, selon (ISO 8402), à apporter la confirmation par examen et apport de preuves tangibles (informations dont la véracité peut être démontrée, fondée sur des faits et obtenues par observation, mesure, essai ou autres moyens) que les exigences spécifiées ont été satisfaites. Cette activité est indissociable de toute activité de modélisation et devient ainsi incontournable dans l'ingénierie de systèmes complexes [START_REF] Meinadier | Ingénierie et intégration des systèmes[END_REF][START_REF] Feliot | Modélisation de systèmes complexes : intégration et formalisation de modèles[END_REF]. Les modèles résultant, outre le fait évident d'être syntaxiquement corrects, doivent en effet répondre de manière adéquate aux besoins et aux objectifs du modélisateur puis être exempts d'erreurs et d'ambiguïtés. Quand elle est mise en oeuvre, la vérification peut être menée à bien au travers :

-D'une série d'interprétations plus ou moins subjectives car liées et dépendantes d'une certaine expérience, de certaines hypothèses ou d'un point de vue particulier. C'est en effet le modélisateur lui-même ou un expert qui va mener à bien cette interprétation soit à partir du modèle directement soit à partir des résultats d'exécution de celui-ci, c'est à dire des résultats d'une simulation ou d'une émulation. La simulation s'appuie généralement sur une exécution symbolique. Bien que relativement outillée [START_REF] Kelton | Simulation With Arena[END_REF] et assez aisée à mettre en oeuvre maintenant, cette simulation n'est cependant possible que si une sémantique opérationnelle (des règles d'initialisation, d'exécution et des hypothèses temporelles) est définie sans ambiguïté pour le langage de modélisation utilisé. De même, l'émulation d'un modèle nécessite des règles de traduction non ambiguës et formelles permettant effectivement d'exécuter un modèle équivalent à celui en cours d'étude. Les techniques d'analyse basées sur la simulation, l'émulation ou les tests sont largement utilisées pour vérifier expérimentalement que l'on obtient des résultats corrects à partir d'un échantillon de données initiales. Cela rassure quelque peu l'utilisateur mais n' exclut pas des résultats erronés en raison de la non-exhaustivité des cas envisagés. -De l'étude des résultats fournis par des outils de preuves formelles de propriétés. Cela est possible, bien que restreint seulement à certains domaines d'application, avec des outils tels qu'un démonstrateur de théorèmes (AtelierB 2004) ou un vérificateur de modèles [START_REF] Holzmann | The Spin Model Checker[END_REF]. Bien que fournissant une preuve irréfutable, ce type de vérification n'est envisageable que si le langage de modélisation utilisé pour bâtir le modèle est basé sur un formalisme autorisant l'expression et la vérification de propriétés. C'est par exemple le cas de la logique temporelle (comme CTL, Computational Tree Logic proposée par [START_REF] Grumberg | Model Checking[END_REF]) ou encore de la méthode Z [START_REF] Spivey | The Z Notation, Collection Méthodologies du logiciel[END_REF]. Cependant, l'usage de tels langages formels nécessite un compromis entre puissance, pertinence, rigueur, lisibilité du modèle et l'expression des propriétés [START_REF] Lamboley | Proposition d'une méthode formelle d'automatisation de systèmes de production à l'aide de la méthode B[END_REF]. En particulier, la manipulation des outils de preuve actuellement disponibles nécessite une compétence et des délais de modélisation dont l'acteur au sein d'une entreprise ne pourra facilement disposer.

Pour ces raisons, la vérification formelle est souvent très marginalement abordée, et peu outillée dans le domaine de la modélisation des processus opérationnels en Entreprise [START_REF] Vernadat | Techniques de Modélisation en Entreprise : Application aux Processus Opérationnels[END_REF]. Cet article propose une alternative intéressante aux deux modus operandi cités ci-dessus. Il s'agit d'une approche de vérification qui tente de concilier les aspects formels (avec les qualités que l'on lui prête habituellement de certitude et d'exhaustivité des résultats) et les aspects liés à la facilité d'application comme le temps de mise en oeuvre (permis habituellement par la simulation par exemple) qui sont absolument nécessaires pour être utilisable en milieu industriel.

Problématique

Le cycle de vie d'un système comporte des phases incontournables d'analyse par vérification (« ai-je bien construit le modèle ? ») puis par validation (« ai-je construit le bon modèle ? celui qu'il me faut ? ») qui peut se schématiser dans la Figure 1. La phase de modélisation proprement dite, symbolisée par une simple flèche dans cette figure, est soumise à de nombreux problèmes susceptibles de remettre en cause la valeur de l'analyse future du modèle :

-le point de vue adopté par le modélisateur peut être plus ou moins clair et stable tout au long du processus de modélisation, -les hypothèses retenues limitent l'expressivité et la précision du modèle qu'elles soient propres au type de système modélisé ou induites par le langage de modélisation utilisé (plus ou moins pertinent ou adapté à un domaine d'application), -la perspective d'analyse future qui sera utilisée par le modélisateur peut être difficile à percevoir, -la méconnaissance voire l'oubli simple de certaines caractéristiques importantes de l'environnement d'évolution du système offrent alors une vision réduite des possibilités d'évolutions du système. Il résulte de cela qu'une partie de la connaissance pourtant nécessaire pour pouvoir ensuite vérifier, ce qui est le but de ce travail de recherche, ce modèle reste méconnue, absente ou ambiguëe. Cette vérification permettra en effet de chercher à s'assurer de la qualité et de la pertinence du modèle pour pouvoir fonder une idée, un jugement ou encore tester une situation particulière du système.

L'absence de cette connaissance peut se justifier objectivement car elle peut apparaître comme dénuée d'intérêt pour le modélisateur, ou subjectivement par une simple méconnaissance des situations complexes (Le Moigne 1999) dans lesquelles le système peut être amené à évoluer. Il serait alors souhaitable de faire émerger, tôt ou tard, cette connaissance pour mieux comprendre certains effets non prévus à l'origine et pour améliorer le modèle du système voire se poser des questions sur le système lui-même. Chaque phase de l'analyse, comme le montre la Figure 1, met en oeuvre des outils de vérification syntaxique (non traités ici), sémantique et comportementale comme la simulation, l'émulation ou la preuve de propriétés comportementales. Elle peut avoir un résultat plus ou moins discutable selon le niveau de formalisation du modèle analysé, des règles et des mécanismes de preuve et / ou d'exécution mis en oeuvre. [START_REF] Moncelet | Application des réseaux de Petri à l' évaluation de la sûreté de fonctionnement des systèmes mécatroniques du monde automobile[END_REF]) et l'ingénierie des besoins [START_REF] Rolland | De la Modélisation Conceptuelle à l' Ingénierie des Besoins[END_REF]. Si l'on considère tout particulièrement le domaine de la modélisation d'entreprise, de nombreux langages, méthodes et cadres de référence ont été développés : PSL (Process Specification Language) (ISO 18629), GERAM (Generalized Enterprise Reference Architecture and Methodology) [START_REF] Bernus | A Framework to Define a Generic Enterprise Reference Architecture and Methodology[END_REF], (ISO 19439), (ISO 19440), CIMOSA (AMICE 1993), GRAI-GIM (GRAI Integrated Methodology) [START_REF] Doumeingts | GRAI Grid Decisional Modelling[END_REF], ACNOS (El Mahmedi 1997), Olympios [START_REF] Haurat | Le modèle OLYMPIOS, un outil d'analyse et de conception du système d'informations des entreprises manufacturières[END_REF]. Cette liste n' est évidemment pas exhaustive. La plupart de ces approches restent encore dépourvues de mécanismes autorisant des phases de vérification à proprement parlé. On peut cependant citer par exemple le langage PSL [START_REF] Bock | PSL: A Semantic Domain for Flow Models[END_REF] qui intègre des mécanismes de vérification des spécifications. De même, d'autres travaux [START_REF] Hilger | Production Management Language[END_REF], [START_REF] Dubois | Agent-Oriented Requirements Engineering: A case Study using the ALBERT Language », 4ème Conférence internationale Dynamic Modelling and Information System, DYNMOD-IV[END_REF] ou [START_REF] Zoetekouw | An overview of formal semantics specification methods, Enterprise Integration Modelling[END_REF]) ont abordé le problème de formalisation des processus d'entreprise. Ainsi, le langage Albert II [START_REF] Dubois | Agent-Oriented Requirements Engineering: A case Study using the ALBERT Language », 4ème Conférence internationale Dynamic Modelling and Information System, DYNMOD-IV[END_REF] permet une description formelle des besoins afin de faciliter leurs validations grâce à la génération de scénarios. Ces travaux se rapprochent notamment des besoins de validation liés à l'approche CIMOSA.

L'approche proposée dans cet article est basée sur un ensemble de concepts et d'outils permettant simultanément :

-De représenter de la connaissance nécessaire à l'expression précise d' un besoin servant de support à la spécification du système et à la description de son modèle. -D'assurer de manière formelle l'exploitation de cette nouvelle connaissance pour vérifier le modèle.

Démarche

La démarche décrite ci-dessous (Kamsu 2004) vise à fournir une aide durant les phases d'analyse des modèles de systèmes complexes, tels qu'un processus dans une entreprise, par la spécification et la vérification formelle de propriétés. La démarche proposée permet ainsi de faire référence aux même concepts (homogénéité du vocabulaire) tant pour décrire les modèles de processus d'entreprise que les graphes de propriétés et les graphes conceptuels qui permettront d'analyser ces modèles. Ensuite, la représentation graphique des connaissances permet à des utilisateurs de comprendre, créer ou modifier directement cette connaissance de façon beaucoup plus simple qu' avec une représentation sous forme de formules logiques par exemple. Enfin, le cadre formel fournit par les graphes conceptuels permet de lever toute ambiguïté par une unique interprétation, interprétation basée sur des mécanismes fournissant des traces du raisonnement, traces éminemment intéressantes pour faciliter les modifications et améliorations ultérieures du modèle. Afin d'aider le lecteur à comprendre et à appliquer concrètement les différents concepts proposés dans cette approche, un exemple de mise en oeuvre des étapes de modélisation et d'analyse est détaillé dans la suite du document. Cet exemple part d'un processus d'entreprise devant être modélisé puis vérifié avant de pouvoir prendre un certain nombre de décisions d'amélioration. Ce processus décrit les étapes nécessaires à la production puis à l'expédition d'un article à partir d'une commande client. Il décompose en trois processus plus élémentaires :

! " # $ %$ # $ %$ & ' ( ' ) & ' ( ' ) $ Experts Experts * 1 -Définir le vocabulaire (Conceptualiser)

-Analyser par vérification de propriétés

Modélisateur/Analyseur

-Modéliser

-La prise en compte de la commande client via un centre d' appels téléphoniques.

Une fois cette commande enregistrée, il faut vérifier sa faisabilité technique et contractuelle puis la valider afin de lancer les ordres de fabrication nécessaires.

Une fois la production terminée, cette activité prendra en charge la facturation, ainsi que l'émission du bordereau d'expédition. -La production de l'article demandé qui comprend la gestion des ordres de fabrication, la fabrication elle-même, l' emballage, l' étiquetage et la mise à disposition de la marchandise.

La gestion des exceptions relatives à des cas particuliers qui comprennent la modification des commandes, la planification des commandes répétitives et le traitement des ordres de retour, par exemple en cas de rupture de stock temporaire, de même que le traitement d'un article inconnu et le fonctionnement en marche dégradée.

Phase de Modélisation

Modélisation du processus

La modélisation du processus nécessite dans un premier temps de choisir le langage de modélisation de processus à utiliser. Celui-ci est inspiré de UEML 1.0. (Unified Enterprise Modelling Language) (UEML 2003) dont une version du méta modèle est donnée dans la Figure 3. UEML définit un ensemble de concepts et de relations communs à certains langages de modélisation d'entreprise existants. Ces concepts et relations sont décrits dans le méta modèle sous forme de classes et de relations en utilisant le langage de classe de UML [START_REF] Booch | The Unified Modelling Language User Guide[END_REF]. Chaque classe et chaque relation sont définies en détail en annexe de (UEML 2003). La construction d'un modèle de processus vise généralement à fournir une aide à la conception, à l'analyse ou à la réorganisation, mais que faire de ce modèle si on ne peut s'assurer de sa complétude, de sa cohérence, de sa validité au regard de l'utilisation qui en sera faite ? La démarche consiste donc maintenant à modéliser la connaissance manquante ou devant être vérifiée au travers de propriétés avant de procéder à la vérification au moyen de mécanismes décrits plus loin

Modélisation de la connaissance sous forme de propriétés

L'idée de base, développée à partir des travaux de [START_REF] Lamine | Définition d'un modèle de propriété et proposition d'un langage de spécification associé : LUSP[END_REF], est de fournir un modèle unique et formel de représentation de connaissances, baptisé classiquement propriétés, qui permet de compléter ce que le modélisateur exprime déjà dans son modèle (de manière plus ou moins adaptée à tout mécanisme de vérification par la suite) sur ce qu'il sait explicitement ou implicitement du système. En effet, [START_REF] Lamine | Définition d'un modèle de propriété et proposition d'un langage de spécification associé : LUSP[END_REF] précise que 'Toute propriété traduit une attente, une exigence, une finalité que l'entité doit satisfaire'. Elle doit donc soit être prouvée sur le modèle du système lorsque cela est possible, soit amener une connaissance supplémentaire qui peut s'avérer bénéfique à terme pour le modélisateur.

A titre d'exemple, modéliser un système de convoyage de bidons remplis d'acide présentant un très grand risque pour d'éventuels opérateurs à proximité nécessite de disposer d'informations relatives à la mécanique du système de convoyage, de la puissance électrique disponible, des produits transportés, du type de risque encouru, etc. Toutes ces informations peuvent ne pas être représentables en utilisant le seul langage de modélisation proposé.

Ainsi, un langage de modélisation de propriétés baptisé CRED (Causes, Relation, Effets, Degré) a été développé. Dans ce langage, une propriété est définie par une relation de causalité R entre l'ensemble C des données et des informations appelées causes et l'ensemble E des données et des informations appelées effets. Cette relation R peut être typée comme suit :

-Logique (Implication ou Equivalence sans notion de temps ou de durée d'application), -Temporelle (les notions d'instants ou d'intervalles de temps permettent de définir, par exemple, la précédence : les causes précèdent toujours les effets), -Influence (la connaissance que l'on a de la cause modifie, avec un sens de variation donné qui peut être interprété comme bon ou mauvais, l'opinion que l'on a sur l'effet), -Emergence (l'effet de la propriété est alors caractérisé par l'apparition ou la disparition d'une autre propriété appartenant à un autre niveau de détail).

Enfin, D est le degré de détail de la propriété. Ces degrés sont ordonnés sur une échelle de référence appelée Granularité G choisie par le modélisateur. Il peut s'agir d'une granularité basée sur les niveaux de décomposition utilisés dans un modèle (respectant par exemple des règles de décomposition comportementale ou fonctionnelle) ou basée sur une structuration arbitraire du système que l'on souhaite décrire.

La notation formelle des propriétés (non présentée ici) permet d'accéder, via une traduction vers d'autres langages formels, à des techniques de preuve existantes sur le marché et largement outillées. Des prouveurs de théorèmes (theorem prover) comme Z-eves [START_REF] Saaltink | The Z/EVES 2.0 User's Guide, TR-99-5493-06a[END_REF]) ou des vérifieurs de modèles (model checker) comme SMV (MacMillan 2000) peuvent ainsi permettre de vérifier certaines propriétés. Un theorem prover permet une vérification interactive qui repose sur la construction progressive d' axiomes ou de théorèmes à partir d' une théorie de base. A l'opposé, la vérification par un model checker est basée sur l'exécution complète, éventuellement symbolique, d'un modèle du système étudié. Tous les comportements possibles du modèle étant explorés systématiquement, la vérification des propriétés exprimées dans une logique particulière, souvent temporelle, devient alors possible. Il s'agit alors de prouver certaines propriétés de :

-Sûreté : Quelque chose de mauvais ne doit pas se produire.

-Vivacité : Quelque chose de bon doit fatalement arriver.

-Sécurité : Quelque chose doit toujours arriver ou Son contraire ne doit jamais arriver. -Atteignabilité : Une situation ou un état donné du modèle sera toujours atteint tôt ou tard.

Considérant le processus décrit Figure 4, le modélisateur peut décrire les propriétés suivantes et ainsi compléter la connaissance qu'il possède sur ce processus.

Propriété 1

La confirmation de l'enregistrement d'une commande est toujours précédée de l'établissement de la faisabilité technique de cette commande. Comme on le voit, le concept de propriété, bien que souvent employé, se voit ici décrit rigoureusement dans un modèle formel. Celui-ci reste cependant encore abstrait par le contenu que l'on peut y mettre. Un grand nombre d'études internationales, dont celle du Standish Group [START_REF] Sgrop | Rapport de recherche interne du standishgroup[END_REF]) ont montré que plusieurs échecs dans la mise en oeuvre et l'utilisation des systèmes industriels sont dus à une mauvaise compréhension des besoins auxquels ces systèmes tentent de répondre. Cette mauvaise compréhension étant régulièrement engendrée par des spécifications déficientes. Le travail effectué a donc consisté à développer une base de connaissances génériques, c'est à dire de propriétés applicables de manière générique à un type de modèle ou de système. Cette connaissance, validée par un groupe d'experts, aide alors le modélisateur à choisir puis à spécifier les propriétés qui paraissent pertinentes vis-à-vis de son système et qui devront ensuite être vérifiées.

Typologie des propriétés

Le référentiel de propriétés définit dans [START_REF] Kamsu-Foguem | Modélisation et Vérification des propriétés de systèmes complexes : Application aux processus d'entreprise[END_REF][START_REF] Chapurlat | A property reference model and associated tools for system life-cycle management[END_REF] -Propriétés Système qui caractérisent les exigences et objectifs, l'aspect structurel, fonctionnel ou comportemental du système lui-même. Elles traduisent (entre autres) des contraintes de déploiement, de sûreté de fonctionnement, de performances, de volumétrie, de confidentialité, d'ergonomie, de maintenabilité, de robustesse [START_REF] Meinadier | Ingénierie et intégration des systèmes[END_REF]), de stabilité ou d'intégrité [START_REF] Penalva | SAGACE : le systémographe, Edition interne au CEA[END_REF]). -Propriétés Modèle qui sont spécifiques à un langage de modélisation. A titre d'exemple, l'on retrouve souvent les propriétés telles que la vivacité, la réinitialisation, le parallélisme ou le blocage dans un langage utilisant le formalisme des automates pour décrire le comportement d'un système. Dans le cas des Réseaux de Petri [START_REF] David | Du Grafcet aux Réseaux de Petri, Deuxième édition revue et augmentée[END_REF], un certain nombre de propriétés générales (réseau vivant, borné, propre, etc.) garantissent que la structure du réseau étudié est correcte. -Propriétés Axiomatiques qui décrivent des connaissances et contraintes irréfutables d'un domaine (lois, normes, standards). Elles sont inspirées par la systémique, l' ingénierie des systèmes ou les cadres de modélisation employés dans certains domaines d' application. C'est ainsi que des propriétés dites de 'temps réel', qu'un domaine impose sur un système, ont été analysées en détail dans [START_REF] Jackson | Problems, Methods and Specialisation[END_REF]. Dans le même ordre d'idée nous pouvons citer les travaux de [START_REF] Feliot | Modélisation de systèmes complexes : intégration et formalisation de modèles[END_REF]) qui ont formalisé des propriétés liées aux attributs de temps, d'espace et de forme pour caractériser les processus de transformation de matières et/ou d'énergie relativement à leurs flux entrants et sortants.

Toutes ces connaissances formalisées offrent l'opportunité aux utilisateurs du référentiel, acteurs de l'entreprise, d'y accéder et de les interpréter ensuite selon leur préoccupation. Ainsi, le modélisateur pourra interpréter et instancier les propriétés à sa disposition puis les paramétrer en tenant compte des éléments constitutifs, de la structure et du comportement du modèle à vérifier et de la finalité de son étude. Ce référentiel constitue donc un véritable guide de spécification des propriétés des systèmes de l'entreprise.

Identification des propriétés

Au niveau méthodologique, l'identification des différentes propriétés est faite par les moyens suivants : analyse du cahier de charges d'un système, investigation du domaine d'application du système (consultation de documents techniques, interaction avec les experts, etc.), étude des similarités entre problèmes, ou encore par la conception d'une liste de questions structurées pouvant guider le modélisateur. Ainsi ce dernier pourra être amené à s'interroger sur les liens existants entre les composants du système et rendre compte de la logique de composition et des contraintes inhérentes, pour retrouver certaines propriétés. Par exemple, la modélisation d'une opération d'assemblage doit faire nécessairement apparaître deux flux d'entrée de produits semi-finis et un flux de produits élaborés au moins. Le modélisateur devra aussi prendre en compte les possibilités de changement (comme le renouvellement de ressources) ou d'évolution comportementales des éléments du système. Enfin la découverte d'autres propriétés peut s'effectuer en recherchant les éléments justifiant la présence d'un besoin sur le système, en voulant définir le degré de complétude des besoins ou encore en exprimant les exceptions aux propriétés déjà existantes. L'utilisation d'un unique langage de modélisation, CRED (Causes, Relation, Effets, Degré), permet ainsi de représenter toutes les propriétés d'un modèle de manière homogène et formellement établie. Chaque propriété est ainsi un grain de connaissance qui partage certaines causes ou certains effets avec d'autres propriétés. On voit alors apparaître une structure de graphe de propriétés [START_REF] Kamsu-Foguem | Enterprise Model Verification : a Graph-based Approach[END_REF] dont les noeuds sont des causes et des effets, éventuellement commun à plusieurs propriétés, et dont les arcs représentent les différents types de relations possibles entre ces causes et ces effets. Des informations pertinentes sur le modèle vont découler de l' analyse de ce graphe de propriétés. Par exemple, il peut s'avérer que certaines propriétés sont insuffisamment décrites et nécessitent des compléments d'information (valeur d'un attribut ou toute caractéristique propre à un système spécifique) afin d'être utilisables dans une démarche de vérification formelle telle que celle présentée maintenant.

Phase d'analyse par vérification de propriétés

On peut distinguer deux approches principales à la vérification formelle [START_REF] Monin | Introduction aux méthodes formelles[END_REF]:

-Celle qui met en oeuvre un système d' inférence, c' est-à-dire un ensemble bien défini et formalisé de règles de raisonnement issues de la logique (modus ponens, récurrence, substitution de valeurs égales, etc.). -Celle qui se fonde sur la construction d' un modèle généralement fini qui représente le système d'état/transition décrivant le comportement de l' application modélisée. La vérification des propriétés s' effectue en parcourant exhaustivement ce modèle.

Toutefois, certains facteurs limitatifs (indécidabilité, explosion combinatoire, temps d'apprentissage, etc.) font que la mise en oeuvre de ces techniques de vérification formelle n' est pas triviale et par conséquent souvent restreinte à certains systèmes dits critiques [START_REF] Rushby | Using Model Checking to Help Discover Mode Confusions and Other Automation Surprises[END_REF]. Nous soulignons alors l'importance de «démocratiser » ces approches formelles par l'utilisation de formalismes souples (lightweight formals methods [START_REF] Jackson | Lightweight Formal Methods[END_REF])), de type conceptuel par exemple, à même de transcrire le vocabulaire du domaine de modélisation enfin de promouvoir des actions de vérification plus efficace et mieux accessible.

Vers des mécanismes d'Intelligence Artificielle

On peut raisonnablement estimer que plus les notions manipulées au travers d' un langage formel sont concrètes -proches de l' expérience des utilisateurs -plus ce langage est facilement accessible. Notre choix pour la représentation des modèles et des propriétés à vérifier s'est alors orienté sur le formalisme des graphes conceptuels [START_REF] Sowa | Conceptual Structures : Information Processing in Mind and Machine[END_REF]. En effet ce formalisme nous semble parfaitement adapté à la formalisation du vocabulaire d'un domaine de modélisation, car sa syntaxe précise permet de décrire les différentes constructions autorisées et sa sémantique rigoureuse permet d'exprimer sans ambiguïté le sens des constructions syntaxiques. De plus, il est doté de mécanismes de raisonnements permettant d'établir des propriétés sur les constructions réalisées et ceci de manière lisible, y compris par les non-spécialistes. D'autres langages (RDF, DAM-OIL, OWL) liés au Web sont parfois utilisés pour la représentation et l' échange de connaissances. Cependant, comparée aux graphes conceptuels, ils ont des mécanismes d' inférences limitées [START_REF] Delteil | Le modèle des graphes conceptuels pour le web sémantique Extensions de RDF et RDFS basées sur le modèle des graphes conceptuels[END_REF].

La section suivante expose, une description du formalisme, inspirée de celle définie dans [START_REF] Mugnier | A Graph-based Approach to Knowledge Representation[END_REF].

Présentation du formalisme

Les graphes conceptuels sont un langage de représentation des connaissances, proposé par John Sowa, permettant à la fois de définir rigoureusement un vocabulaire (i.e ontologie) et d'utiliser ce vocabulaire pour décrire et raisonner sur des situations. D'un point de vue représentation de connaissances, les graphes de Sowa apportent une structuration des différents types de connaissance qui n'est pas explicite dans d'autres formalismes comme les réseaux sémantiques ou UML. En effet, ce formalisme marque une séparation nette entre les connaissances ontologiques (encodées dans une structure particulière appelée support) et les connaissances factuelles qui sont représentées par les graphes. De plus, le formalisme distingue clairement les entités (représentées dans le graphe par des rectangles) des relations entre ces entités (représentées par des ovales). L'ontologie formelle du domaine de modélisation est alors constituée par la construction d'un support formé des treillis de concepts et de relations. Toutefois, les travaux de Sowa [START_REF] Sowa | Knowledge Representation: Logical, Philosophical, and computational Foundations[END_REF] ne précisent pas la manière d'obtenir cette ontologie à partir d'un corpus informel. Cela nous a conduit à définir une méthode de construction progressive d'ontologie formelle.

Définition

Représentation du domaine : Ontologie de la Modélisation d'Entreprise

La modélisation en entreprise, par sa nature pluridisciplinaire, contient beaucoup de termes différents ayant la même sémantique. Il faut utiliser donc un moyen de conception qui peut normaliser tous les termes employés afin de lever toute ambiguïté. C'est dans le concept d'ontologie que ce problème trouve sa solution. L'ontologie a pour fonction en effet de spécifier explicitement concepts et relations [START_REF] Gruber | A translation approach to portable ontology specifications[END_REF], c'est à dire de les rendre compréhensibles et utilisables par plusieurs agents (humains ou logiciels).

Nous nous sommes inspirés des travaux de [START_REF] Guarino | Understanding, Building, and Using Ontologies: A Commentary to Using Explicit Ontologies in KBS Development[END_REF]) pour définir une démarche générique de construction d'ontologie formelle qui est appliquée ici à modélisation d'entreprise. Cette démarche de formalisation comporte deux étapes. En s'appuyant sur des travaux existants (PSL [START_REF] Schlenoff | The Essence of the Process Specification Language[END_REF], UEML [START_REF] Vernadat | UEML : Toward an Unified Enterprise Modelling Language[END_REF][START_REF] Ueml | Delivrable D3.1: Requirements analysis: initial core constructs and architecture, Unified Enterprise Modeling Language UEML Thematic Network[END_REF], SAGACE [START_REF] Penalva | SAGACE : le systémographe, Edition interne au CEA[END_REF], TOVE [START_REF] Gruninger | Ontologies to Support Process Integration in Enterprise Engineering[END_REF]), la première étape consiste à bâtir une représentation intermédiaire de l'ontologie avec la notation UML (OMG 2003) (on parle alors de conceptualisation). Quant à la deuxième étape, elle permet de dériver une description formelle et structurée en treillis de l'ontologie initiale (transformation appelée opérationalisation).

Schématiquement parlant, le processus général de construction d'ontologie est scindé en deux phases comme le montre la Figure 6. L'obtention d'une ontologie formelle constitue un élément qui pour nous est primordial, car ceci sert divers aspects du développement de notre approche d'analyse des modèles d'entreprises. Tout d'abord cette ontologie formelle assiste le processus de construction de spécification de modèle, en rendant les documents de spécification mieux compréhensibles et plus précis. Cette précision favorise l'interopérabilité entre des paradigmes, des langages ou des outils différents. En outre, elle soutient la démarche de raisonnement pour la vérification des propriétés de modèle.

Outils de raisonnements

Parmi les travaux s' attachant à utiliser le formalisme des graphes conceptuels comme un langage opérationnel deux grands courants se distinguent :

-Le premier consiste à considérer le langage comme une simple notation graphique de la logique des prédicats du premier ordre [START_REF] Amati | Conceptual Graphs and First Order Logic[END_REF]. Les raisonnements sont alors effectués, après traduction des graphes en formules logiques, en utilisant des algorithmes de résolution logique. Le système Prolog+CG [START_REF] Kabbaj | From PROLOG++ to PROLOG+CG : A CG Object-Oriented Logic Programming Language[END_REF] fournit une vision représentative d'une telle approche ; -Le second vise à concevoir le langage comme une notation formelle disposant d' opérations de raisonnement (basées sur le morphisme de graphes) internes à la notation, mais conservant les propriétés de consistance et complétude vis à vis de la logique des prédicats du premier ordre, ce qui permet de doter ce formalisme d' une "sémantique" formelle. Le système CoGITaNT [START_REF] Genest | CoGITaNT Version-5.1 -Manuel de référence[END_REF] relève de cette approche.

Nous plaçons nos travaux dans ce deuxième courant qui, grâce à son aspect graphique tant du point de vue de la représentation des connaissances que des mécanismes de raisonnement, nous semble être un candidat idéal pour notre problématique. En effet, Prolog ayant l'inconvénient de ne pas disposer de sémantique déclarative, il en résulte que le résultat d' une inférence peut dépendre de la forme de la base de connaissances (ordre des clauses ou des conjonctions), conduisant ainsi à des résultats différents pour deux bases de connaissances sémantiquement équivalentes.

Preuves de propriétés avec les opérations de graphes

En accord avec [START_REF] Mugnier | Knowledge Representation and Reasonings Based on Graph Homomorphism[END_REF], nous pensons que la projection est l' opération fondamentale de raisonnement dans le formalisme des graphes conceptuels. Cette projection est une sorte d'appariement de graphes, qui peut être facilement visualisé et interprété. Par exemple si nous souhaitons répondre à la question « est ce que la propriété représentée par un graphe (requête) H est présente dans un référent également décrit par un graphe G ? ». Cet opérateur de recherche d'informations nous permet d'y répondre et la vérification de la propriété va consister à rechercher les projections possibles de H dans G.

Dans la Figure 7 par exemple, à partir du graphe d'une situation décrivant partiellement deux activités précises et en posant une requête sous forme d'un graphe question, nous parvenons à prouver la présence d'une commande en sortie d'une activité. Cette preuve par projection du graphe requête dans le graphe situation, est fondée sur un calcul de spécialisation entre les deux graphes. Pour réaliser des raisonnements plus poussés s'appuyant sur cette projection, nous allons mettre en oeuvre d'autres types des connaissances de différente nature : règles (d' inférence, d' évolution) et contraintes [START_REF] Baget | Extensions of Simple Conceptual Graphs: the Complexity of Rules and Constraints[END_REF].

Compléter les représentations avec les règles de graphes

Les outils de modélisation d'entreprise sont souvent descriptifs et font appel à une collection d'heuristiques qui ne sont pas applicables en toutes circonstances. Il est donc nécessaire de recueillir et de formaliser les principes de modélisation d'entreprise qui sont implicitement présents dans ces heuristiques. C'est dans cette optique qu'interviennent les règles de graphes conceptuels, pour décrire ces connaissances implicites sous forme de propriétés dont la prise en compte favorisera l'enrichissement ou l'évolution de modèles. Par exemple la règle « si une entreprise a des flux de fabrication discontinus, alors elle utilise des ateliers avec stockage » peut permettre de déterminer, par inférence de nouvelles connaissances, les en-cours de production d'une entreprise.

De manière générale, nous définissons deux types de règles :

-les règles statiques pour exprimer certaines lois immuables du domaine [START_REF] Salvat | Raisonner avec des opérations de graphes: graphes conceptuels et règles d'inférence[END_REF]. Par exemple une règle statique pourra être utilisée pour exprimer la symétrie d'une relation de proximité géographique ou encore la transitivité d'une relation binaire, notamment le parallélisme (Figure 8).

-les règles dynamiques pour modéliser les évolutions du monde avec les conditions de changement d'états [START_REF] Bos | Modéliser Pour Simuler Pour Modéliser : Contribution à l'Acquisition de Connaissances Comportementales[END_REF]. En particulier, une règle dynamique permettra de modéliser des propriétés du type : « si deux activités Ai et Aj se suivent et que l'activité Ai traite des produits (pièces, données, etc.) alors une voie de communication doit assurer la transmission de ces produits vers l'activité Aj » (Figure 9).

Valider avec les contraintes

Dans le modèle de base des graphes conceptuels, le raisonnement est limité à la démonstration de la vérité de propriétés positives (i.e. équivalentes à des formules conjonctives positives). Cependant, nous avons parfois besoin de démontrer la vérité ou la fausseté de graphes ou de morceaux de graphes pour prouver l'éxécutabilité ou la non exécutabilité des actions. C'est ainsi qu'apparaissent les contraintes comme graphes qui servent à effectuer la vérification de la validité d'un modèle représenté par un ou plusieurs autres graphes.

Une contrainte est composée d'une partie conditionnelle et d'une partie obligatoire. La partie conditionnelle est un graphe simple qui peut être vide [START_REF] Baget | Représenter des connaissances et raisonner avec des hypergraphes : de la projection à la dérivation sous contraintes[END_REF]. Nous considérons deux types de contraintes : les positives et les négatives. Intuitivement, une contrainte positive exprime une propriété du genre: 'Si l'information A est présente, alors l'information B doit être aussi présente'. Une contrainte négative exprime une propriété du genre: 'Si l'information A est présente, alors l'information B doit être absente'. En d'autres termes, ces contraintes de graphes permettent de bien étudier à la fois la cohérence d'un modèle (il ne doit pas contenir de connaissances décrites dans les contraintes négatives) et la complétude du modèle (il doit contenir les connaissances décrites dans les contraintes positives).

La Figure 10 représente deux contraintes, une contrainte négative C -qui peut s'exprimer par "toute activité qui déclenche une alarme ne doit pas rester en état d'exécution" et une contrainte positive C + , qui peut s'exprimer par "tout atelier de fabrication doit être doté au moins d'une machine". Munis de l'ensemble de ces opérations de graphes (projections, règles et contraintes) comme outils de raisonnements, nous pourrons concrétiser la vérification de propriétés, car nous serons en mesure de garantir qu'un référent (modèle de processus) se comporte correctement relativement à un ensemble de propriétés, qui peuvent être des connaissances expertes ou exigées par des utilisateurs.

Au niveau applicatif, pour qu'un processus soit véritablement intégré dans les politiques organisationnelles d'une entreprise, il est habituellement nécessaire d'une part que les lois du domaine soient satisfaites et d'autre part que l'exécution de ce processus soit conforme à la description de sa spécification (UEML 2002). Ce constat nous impose de pouvoir représenter explicitement, via des procédures de vérifications par preuves de propriétés, la différence entre le comportement requis et le comportement réel des processus. Par exemple, on peut vouloir s'assurer que "le service des ventes doit répondre à la commande d'un client dans un délai de 48 heures". Ainsi, le problème précédent revient à savoir si des politiques (managériales, organisationnelles, etc.) sont transgressées durant l'exécution des processus. De cette manière, une activité de notification peut être déclenchée par le non-respect d'une propriété spécifiée afin de prévenir un responsable de l'entreprise.

Exemple

Dans cette section, nous allons prouver deux des six propriétés vues plus haut en utilisant des mécanismes différents afin de bien illustrer le potentiel de l'approche proposée.

Les éléments algorithmiques de la traduction d'un modèle de processus en graphe conceptuel étant présentés dans (Kamsu 2004). On retiendra essentiellement les deux traitements opérés sur les activités et leurs enchaînements. Les activités {fabriquer, expédier,...} sont traduites dans le formalisme des graphes conceptuels suivant leur marqueur respectif (individuel, générique ou variable). Quant aux enchaînements {successeur, parallèle,…} des activités, ils sont traduits en relations conceptuelles liant les graphes des activités.

Preuve directe de la propriété P 1

La démarche de preuve directe consiste à prouver des propriétés par la mise en oeuvre d'un ensemble de raisonnements déductifs. Dans cette section nous allons appliquer ce principe de preuve pour démontrer la propriété P 1 suivante : P 1 " La confirmation de l'enregistrement d'une commande est toujours précédée de l'établissement de la faisabilité technique de cette commande ".

Pour la réalisation de cette preuve directe nous allons utiliser la règle R 1 et la contrainte positive C 1 , représentées ci-dessous : R 1 " Si l'enregistrement d'une commande est confirmé, alors cette commande est expédiée ".

C 1 " Pour qu'une commande puisse être expédiée, il faut qu'elle est un agrément de faisabilité technique ".

La démonstration de la propriété P 1 se fait en deux étapes : elle consiste à appliquer la règle R 1 au graphe décrivant une activité du processus, puis à prendre en compte une contrainte du domaine afin d'établir la consistance du graphe résultant. Finalement, la preuve est établie, puisqu'il existe une projection de la propriété dans le dernier graphe construit. La Figure 11 illustre les étapes de raisonnement associées. Nous rappelons que la preuve par l'absurde est une technique de démonstration qui vérifie la vérité d'une proposition en établissant la fausseté des conséquences de sa contradictoire. Nous voulons démontrer par l'absurde la propriété P 3 à l'aide des graphes conceptuels. La propriété P 3 est la suivante : P 3 "Si on utilise un type de procédé de fabrication alors le matériau utilisé et la géométrie des objets produits ont des caractéristiques indissociables de ce procédé".

Pour la réalisation de cette preuve par l'absurde nous allons utiliser la règle R 3 et la contrainte négative C 3 , représentées ci-dessous : R 3 " Si deux produits donnés ont des attributs géométriques différents, Alors ils sont différents ".

C 3 " Deux activités de fabrication équivalentes doivent fournir en sorties des produits identiques ".

Concrètement nous essayons de démontrer l'équation suivante :

Règle R 3 ∧ Contrainte C 3 Propriété P 3 ?

Ce qui équivaut à écrire :

Propriété P 3 fausse Règle R 3 fausse ∨ Contrainte C 3 fausse ?

La démonstration par l'absurde est formalisée en graphes conceptuels comme suit:

-L'hypothèse de départ de la démonstration "supposons qu'il existe deux produits ayant des attributs géométriques différents et qui sont issus de deux activités de fabrication équivalentes A1 et A2" est représentée par le graphe Gh de la Figure 12. -La violation de la contrainte C 3 sur le graphe de Figure 13, met en évidence une contradiction sur ce graphe. Ceci conduit au rejet de l'hypothèse supposant que la propriété P 3 est fausse . On conclut donc que la propriété P 3 est vraie.

L'intérêt pratique de cette propriété est que l'utilisateur désirant produire des pièces avec des caractéristiques spécifiques, saura dans son contexte recourir à l'atelier adéquat pour exécuter sa tâche.

Conclusion

La vérification de propriétés de modèles de systèmes complexes, tels que des processus au sein d'une entreprise, est une activité délicate qui peut grandement influencer le fonctionnement et les performances de cette entreprise ou du réseau de partenaires dans lequel elle est impliquée. Les outils mis alors à disposition des ingénieurs et des décideurs doivent donc non seulement être aptes à représenter convenablement la réalité d'une situation, mais aussi permettre son interprétation de manière précise pour faciliter la compréhension de la complexité et améliorer la confiance dans les représentations à des fins d'argumentation de choix en situation de décision et/ou d'action.

L'approche proposée comprend une ontologie formelle du domaine et s'appuie sur les opérations des graphes conceptuels pour vérifier les propriétés des modèles d'entreprise. Ces opérations de graphes permettent la mise en oeuvre de raisonnements directement visualisables. Cela offre aux différents acteurs la possibilité d'améliorer les modèles considérés en fonction des résultats de preuve et de leur réflexion. Les perspectives de ce travail sont nombreuses. On peut citer,

Figure 3 .

 3 Figure 3. Méta modèle (hors attributs de classes) de UEML[START_REF] Ueml | Delivrable D3.1: Requirements analysis: initial core constructs and architecture, Unified Enterprise Modeling Language UEML Thematic Network[END_REF]

Figure 4 .Figure 5 .

 45 Figure 4. Le processus de traitement des commandes décrit avec GME[START_REF] Gme | Generic Modeling Environment (GME) version 4: User's Manual 2004[END_REF]

:

  Un graphe conceptuel simple est un graphe biparti, étiqueté, orienté et fini. Les deux composantes formant les noeuds du graphe sont: les concepts et les relations. Un concept est composé d'un type et d'un référent : [<type> :<marqueur>], par exemple [Atelier : AtelierDeFabrication23]. -Le type de concept représente l'occurrence d'une classe d'objets. Ils sont regroupés dans une structure hiérarchique (muni d'un ordre partiel) appelée treillis des types de concepts. -Le marqueur précise le sens d'un concept en spécifiant une occurrence du type de concept. Il peut être de différente nature, notamment individuel ou générique. Une relation conceptuelle lie enfin deux ou plusieurs concepts suivant le schéma suivant : [C1]→(relation)→[C2]. La définition de sous relations est parfois nécessaire pour apporter plus de finesse dans la représentation sémantique, on établit alors un treillis de relations. Chaque relation possède une signature qui fixe son arité et donne les types maximaux de concepts qu'une relation de type peut lier.

Figure 6 .

 6 Figure 6. Construction d'une ontologie formelle

Figure 7 .

 7 Figure 7. Un exemple de vérification par projection

Figure 9 .

 9 Figure 9. Un exemple de règle dynamique

Figure 10 .

 10 Figure 10. Exemples de contraintes

Figure 11 .

 11 Figure 11. Eléments de preuve de la propriété P 1

Figure 12 .Figure 13 .

 1213 Figure 12. Graphe Gh de l'hypothèse de la démonstration

Analyse des modèles par vérification de propriétés : la

	-Définition du vocabulaire : une ontologie du domaine de la modélisation
	d'entreprise est formalisée. Cette formalisation est en soi une activité de
	clarification terminologique au cours de laquelle des concepts plus ou moins
	imprécis doivent être amenés à une expression dénuée de toute ambiguïté. Les
	entités et les relations entre ces entités nécessaires à la modélisation de
	processus d'entreprise dans un univers donné (production, tertiaire, etc.) sont
	ainsi représentées rigoureusement. Ces entités et ces relations s'inspirent
	évidemment des concepts imposés par le langage de modélisation choisi ou
	proposé par d'autres méthodes ou cadres de modélisation de référence du
	domaine concerné, ici la modélisation d'entreprise. Cette première étape ne sera
	pas abordée en détail dans cet article du fait de sa complexité. Le lecteur pourra
	se référencer à (Kamsu 2004, Chapurlat et al., 2005).
	-Modélisation : le processus d'entreprise est modélisé en utilisant le langage
	choisi. En même temps, les propritétés devant être prouvées sur le modèle sont
	choisies et spécifiées par le modélisateur. Ce sont ces propriétés qui fournissent
	ainsi la connaissance non incluse dans le modèle, connaissance pourtant
	nécessaire pour la vérification.
	-vérification nécessite
	+ + de traduire les modèles obtenus dans la phase précédente dans des modèles
	formels exprimés dans le formalisme des graphes conceptuels. Ce formalisme Modélisateur Modélisateur offre en effet divers mécanismes de raisonnement dont l'utilisation est détaillée
	dans la suite. Cette approche permet de s'assurer que ce modèle respecte un
	ensemble de propriétés ou de détecter au contraire des manques ou des défauts
	nécessitant de modifier le modèle ou de spécifier de nouvelles propriétés.
	+ +
	Figure 2. Démarche schématisée et outils support associés
	Cette démarche, schématisée avec ses outils informatiques supports dans la Figure
	2, se décompose en trois étapes essentielles :

  Si on utilise un type de procédé de fabrication alors le matériau utilisé et la géométrie des objets produits ont des caractéristiques indissociables de ce procédé. Un produit est expédié à destination d'un client, si et seulement si il a été contrôlé (qualité, sécurité, etc.) et seulement quand il existe une facture correspondant au bon de commande du client. Soient deux activités A i et A j consécutives (A j suit immédiatement A i ), si A i passe en Arrêt propre alors A j va passer en Arrêt induit.

	Propriété 3
		Cause	Relation de causalité	Effet
	-Procédé de fabrication de type Fi -implication logique	-le matériau dépend de Fi
					-la géométrie des sorties a
					des caractéristiques liées à Fi
	Propriété 4
		Cause	Relation de causalité	Effet
	-Produit Pi a subit un contrôle	-équivalence logique	-Produit Pi expédié à un client
	-La facture liée au BC du client	-antécédence	-Produit Pi respecte les
	Ci pour un produit Pi existe			normes en vigueur
	Propriété 5
		Cause		Relation de causalité	Effet
	-A j suit immédiatement A i	-antécédence	-A j dans l'état arrêt
	-A i dans l'état arrêt propre			induit
	Propriété 6
	La coopération et la coordination des ressources humaines au cours d'une activité
	donnée font apparaître de nécessaires compétences complémentaires entre ces
	ressources.	Cause		Relation de causalité	Effet
	-établissement de la faisabilité technique d'une commande Ci Cause -Coopération et coordination	-précédence temporelle Relation de causalité	-confirmation de Effet l'enregistrement de Ci -compétences
	des ressources humaines de	-émergence	complémentaires pour
	Propriété 2 l'activité Ai			soutenir l'activité Ai
	L'écart entre réalisations effectives d'une activité de fabrication et prévisions
	initiales influence les actions correctives auxquelles cette activité sera soumise.
		Cause		Relation de causalité	Effet
	-Ai activité de fabrication			-actions correctives
	-Ecart =Prévisions (Ai) -Sorties (Ai) -Sorties (Ai) ≠ Prévisions (Ai)	-influence	sur l'activité Ai

  est destiné à améliorer de manière significative la phase de spécification des modèles d'entreprise par la proposition d'un ensemble de propriétés types. En substance, l'objectif de ce référentiel de propriétés est donc de : -Fournir une modélisation systémique et explicite des propriétés usuelles mais déterminantes d'une entreprise et de son environnement. -Faciliter leur accès, partage et réutilisation par les membres de l'entreprise dans leurs tâches individuelles et collectives. -Constituer une valeur ajoutée pour des processus organisationnels et de production, notamment en favorisant la mise à jour et la création de nouvelles propriétés pertinentes pour l'entreprise. -Garantir un ensemble d'éléments concourant à la mise en oeuvre des spécifications appropriées et exhaustives pour un problème particulier. L'architecture du référentiel fournit une vision structurée des propriétés et prenant en compte les divers aspects du système visé. Elle contient trois types de propriétés :


Francois Pfister
email: francois.pfister@mines-ales.fr

V Chapurlat

M Huchard

C Nebut

J.-L Wippler

A proposed meta-model for formalizing Systems Engineering knowledge, based on functional architectural patterns

Keywords: design-pattern, systems engineering, model-based systems engineering, eFFBD

Design patterns and architecture patterns have been considerably promoted by software engineering. The software oriented tools and methods have been adapted for Systems Engineering, conforming to the model driven engineering paradigm proposed by the Object Management Group. However, designers of complex socio-technical systems have specific concerns, which differ from those of software designers. We propose a method of pattern implementation for Systems Engineering, based on a functional approach and relying on formal conceptual foundations in the form of a meta-model, which can be used for the management, application, and cataloguing of patterns specific to the field of Systems Engineering. A pattern instance in the field of control systems is proposed as an example application.

Introduction

Systems Engineering (SE) frames the design of systems characterized by a high degree of complexity, a hierarchical structure (consisting of subsystems), and strong interaction with their environment. Such systems, which meet stakeholders' needs by transforming inputs and consuming resources, consist of several types of components, including technical and physical components (mechanical, electronic), informational (software), and human (operators, pilots).

The design of such systems, even if they are very innovative, does not occur ex nihilo. The problem solving process carried out by the designers relies heavily on heuristic principles.

Heuristics refers to experience-based techniques for problem solving, learning, and discovery.

Heuristic methods are used to speed up the process of finding good solutions, when an exhaustive search would be impractical. In engineering, heuristics include leveraging design and architectural patterns, which are not reusable solutions as is, but must be adapted to the specific context of the problem. They are of value because they enable collective experience to be reused, and time to be saved in design processes. So, even if the whole system seems to be an innovative solution to a given problem, its functions and components are, at a given level of granularity, consistent with patterns of known and tested solutions in response to known and recurring problems. In this way, a system may also be seen as a set of standard solutions interpreted and adapted to a given context. This "pattern vision" is known in many scientific and academic fields (for example in the SE domain, in which we talk about SE Patterns), but it is not always made explicit or formalized.

The questions we would like to address are: 1) What is an SE Pattern? 2) How is an SE Pattern different from other forms of patterns already known in other areas? 3) How can patterns for Systems Engineering be represented, capitalized upon, and reused? 4) Finally, how can they be identified and collected?

In addition to requirement patterns and physical allocation patterns, we hypothesize that an approach based on functional architecture patterns is equally important for knowledge reuse in Systems Engineering. It is therefore necessary to express these functional patterns with a language used by system architects, and propose a meta-model that is compatible and interoperable with those implemented by major SE tools, such as Core [START_REF] Vitech | CORE Architecture Definition Guide (DoDAF v1[END_REF]. Other problems raised by pattern implementation in SE tools are methodological issues: at what stage of the design process should patterns be used? These methodological issues also address the question of SE pattern formalization.

As described by Figure 1, a SE Pattern catalog requires a pattern language that formalizes problems, contexts, and solutions. When and if the language is available (first scientific obstacle indicated by Lock #1), a catalog must then be constituted. Using that language, system architects are able to translate their experience to form a catalog. Other non-formal or differently formalized catalogs, and technology watch, are potential sources for creating the catalog. Finally, SE Patterns may be embedded in existing models and should then be identified by pattern recognition mechanisms, which is the second scientific obstacle (Lock #2). This article presents and illustrates a meta-model for implementing patterns tailored to Systems Engineering, able to manage pattern formalization, collection, and application. Such a SE Pattern meta-model enables both formal and informal pattern representation. It should also help in applying SE Patterns on models being developed. These models must necessarily be expressed using a Systems Engineering meta-model, which is how this paper proposes to make a contribution to this field of knowledge. Finally, our proposition is illustrated by a use case. That contribution is presented in Section 3, after a review of the literature in Section 2. Pattern identification mechanisms are briefly discussed in Section 4. Finally, Section 5 includes the conclusion and points to future work.

[Figure 1 here]

Literature Review

The historical uses of design patterns, their variants, objectives, and formalisms must be examined to determine whether or not they can be reused in the SE field, and to identify some of their limitations. This review is composed of four subsections. The first examines the different design patterns used over time, and in different areas. The second identifies their goals. The third is about formal pattern representation using several tools and modeling environments, in particular UML and SysML. Finally, since the contribution described in this paper concerns functional modeling architecture, the fourth section reviews functional block languages, such as eFFBD.

History of Design Pattern Use

Design patterns in their current forms were proposed in the late seventies by architects and city planners, and adopted in the early nineties by software engineers. Ten years later, Systems Engineers began to promote their use.

A well-known promoter of patterns is Christopher Alexander. He is an English architect and urban planner who was born in 1936, having completed numerous architectural complexes in North America and Japan. He questioned the possibility of making original creations in the field of design. In his view, every cultural, artistic, technical, scientific, and legal form is the result of a transhistorical process, which adapts an "ideal" archetypal model. He argues that all creation is simply an imitation of an original pattern [START_REF] Alexander | A pattern language: towns, buildings, construction[END_REF]. C. Alexander based his theory on functional requirements on the one hand, and cultural models on the other.

The design method promoted by Alexander has been adopted by software engineering [Gamma, E. et al., 1994] [Coplien and[START_REF] Coplien | Pattern Languages of Program Design[END_REF] to optimize software architecture in terms of organization of classes. The basic goal is to improve quality, and facilitate code writing by adopting good practices, which was formalized in a book entitled Design Patterns --Elements of Reusable Object-Oriented Software.

At that time, several communities began to manage pattern catalogs in various domains. For instance, in the field of software engineering, the Hillside Patterns Library started a collection of software patterns. These patterns are generally subject to a peer-review process through the PLoP (Pattern Languages of Programs) conference. The patterns submitted undergo a shepherding process [START_REF] Harrison | The language of shepherding. A pattern language for shepherds and sheep[END_REF], in which they are analyzed and modified before being presented at the conference. The roles and procedures used to frame and make design patterns evolve are greatly influenced by the work of the Hillside Group. The PloP pattern language is essentially textual.

PloP authors emphasize the literary quality of the pattern descriptions; for example, problem statements are carefully crafted into well-defined patterns; if the solution is the heart of the pattern, the problem is its soul [START_REF] Meszaros | A Pattern Language for Pattern Writing[END_REF]. Problem statements for many patterns are too vague, and sometimes the problem statement is solution-oriented. Pattern authors often begin by writing the solution, and the problem comes only as an afterthought. Alternatively, authors begin by writing the problem, and the way the problem is formulated tends to be vague and less precise. Pattern authors also emphasize the notion of forces. Breaking down the forces helps to formulate a clear and in-depth description of the problem solved by the pattern by decomposing that problem. In fact, the problem perceived is a symptom of something that is wrong. The forces at play give substance to the problem, and insight into what is behind the symptoms. The author should go back and forth between the forces and the problem statement to improve both of them.

The purpose of PloP is to promote software patterns, but it is also seeking subjects in domains beyond software. Topics covered include for instance Telecommunications Distributed Processing Patterns and Design Patterns for Avionics Control Systems, which are close to System Patterns.

Following Gamma and Coplien, Martin Fowler proposes analysis patterns [START_REF] Fowler | Analysis Patterns[END_REF], which are not about how code is organized, but about the structure of models that represent real systems. In the area of workflow management [ Van der Aalst, W. et al., 2003] identifies 21 different patterns that describe the behavior of business processes. These patterns, which are described on a website, represent configurations encountered in business processes in general.

They were originally expressed with a specific language (YAWL), but can be transformed into UML Activity diagrams [Bock, 2006] or BPML diagrams. [White, SA, 2004].

However, Van der Aalst patterns are abstract structure patterns (choice, sequence, parallelism, choice, interleaved parallel routing, milestone ...), but they are not as such reusable in concrete business cases or scenarios. These patterns describe generic transverse configurations. Meanwhile, other patterns, which reflect concrete processes in a particular domain, such as the PDCA pattern [START_REF] Appleton | Patterns for Conducting Process Improvement[END_REF]] [Cloutier, R. & Verma, D., 2007], documents a pattern that can be implemented in the field of process management.

In the field of Systems Engineering, patterns have been the subject of many publications within INCOSE. The first article on this subject [Barter, HR 1998] proposed a language of patterns for SE. A pattern language was subsequently proposed for writing [START_REF] Haskins | Using Patterns to Share Best Results -A Proposal to codify the SEBOK[END_REF] a Systems Engineering manual: the Systems Engineering Book of Knowledge (SEBOK). Inter-pattern relations and the establishment of a pattern map have been proposed by the same author [START_REF] Haskins | Application of Patterns and Pattern Languages to Systems Engineering[END_REF]. A proposal for an engineering paradigm based on patterns (PBSE) [Schindel, WD, 2005] was followed by other studies [Cloutier, R., 2006] [Cloutier et al., 2010]. The degree of formalization of these proposals is not yet sufficient, which is what motivated our research and this paper in particular.

Design Pattern Goals and Typology

All these variants have similar objectives: a design pattern is a way practitioners can represent invariant knowledge and experience in design. It can help humans to identify and solve problems by drawing or imitating such knowledge and experience. The objectives are:

• to improve performance (comprehensiveness, relevance), reliability (proven solutions, justified and context-based),

• to gain economic value (time savings) and,

• to facilitate collaborative work by sharing design pattern repositories.

These objectives can be achieved by leveraging and integrating knowledge and good practices.

A design pattern is a simple and small artifact, rarely isolated and therefore correlated with other ones; not a creative method (by definition, it exists only if the solution it proposes is well known and frequently used in the field and, therefore, is not innovative). In the same manner, it is not a reusable component. It is destined to be imitated and adapted to a particular context.

One characteristic of design patterns is that they do not alter the functionality of the models to which they apply. Indeed, a design pattern improves the quality of the current model of a system under design. A design pattern improves non functional features, quality of service and systemic properties. [START_REF] Manola | Providing Systemic Properties (Ilities) and Quality of Service in Component-Based Systems[END_REF] names "-ilities" the operational and support requirements a system must address (availability, maintainability, vulnerability, reliability, supportability …). Often, gaining some "-ilities" is done at the expense of some others: e.g. The Spitfire was designed with an elliptical wing, giving greater speed and maneuverability (perhaps the most critical "-ility" of all for a warplane). But this came at a price: 13000 man-hours per airframe. Willy Messerschmitt had optimized the German Bf 109 for speed and manufacturability at only 4000 man-hours per frame, but the Bf 109 was no faster than the Spitfire and was consistently out-turned by it. The elliptical wing had been considered but ultimately rejected as too difficult to manufacture [START_REF] Alexander | Systems Engineering: -ilities for Victory[END_REF].

Different categories are used to construct taxonomy of patterns:

1. Idiomatic patterns. Describe low level elements that structure a model, govern associations between these elements, and define aggregation and containment strategies (e.g. Composite Pattern). In the software engineering domain, GOF patterns [START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Software[END_REF]] could be classified as such. Workflow patterns, such as the ones proposed by [Van der Aalst, W. et al., 2003], also belong to that family.

2. Generic patterns. This category of high level patterns cuts across several areas. e.g. command-control loop, active redundancy, event queuing, error detection and correction. The example described below illustrates generic patterns.

3. Domain specific patterns. This category of patterns is specific to particular industrial or organizational areas. These patterns, although related to particular technical fields, are however, at a high level, the responsibility of system designers. Many patterns coming from the Hillside repository, as well as Fowler analysis patterns, are domain specific patterns.

Patterns may apply to the system of interest (SOI), or to systems engineering activities (SEA) themselves (which aim to produce a model of the system of interest). In the first case, we speak about SOI patterns, in the second about SEA patterns. Leveraging patterns is efficient for each of three main Systems Engineering activities -requirement engineering, functional architecture design, and physical architecture design. We argue that functional architecture patterns are key elements for knowledge reuse. [START_REF] Cloutier | Applying the concepts of patterns to systems architecture[END_REF] proposed a system architecture taxonomy, in which patterns are broken down into:

1. Structural patterns -provide a physical pattern to follow when designing a part of the architecture.

2. System Requirements patterns -prescribe the format of a properly formed requirement, or a collection of requirements that can be reused to describe desired functionality. This paper addresses only SOI patterns and focuses on functional architecture (Type 5 in Cloutier's taxonomy), whether generic or domain specific targets.

Systems Engineering

Design pattern formalization

Design patterns have been formalized to varying degrees. Often, this formalization is only a standard text template [Portland Pattern Repository]. In contrast, other software design tools based on UML have implemented design pattern catalogs equipped with a true meta-model [START_REF] Galic | Applying Pattern Approaches[END_REF]].

Within models, design patterns apply a crystallization process [Jézéquel et al., 2005 in French].

Impacted entities fit together in a configuration to meet specific roles defined in the pattern.

Design patterns are defined in UML or SysML as parameterized collaborations. They specify a set of classes and objects that have specific roles and interactions. Generally speaking, a parameterized collaboration is used when the actual classes work in the same way as the collaboration classes, but the classes and operations are named differently. Collaboration is a name given to the interaction among two or more classes. Typically this is an interaction as described in an interaction diagram [START_REF] Larman | Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process[END_REF]. Mechanisms such as inheritance, delegation, and implementation are used to give rise to these collaborations, which will be captured by use cases as well as through interaction diagrams. [START_REF] Jacobson | Software Reuse: Architecture, Process and Organization for Business Success[END_REF][START_REF] Sunyé | Design Patterns Application in UML[END_REF]].

Applying a design pattern amounts to generating or correcting part of a model by applying a prototype [START_REF] Barcia | Get started with model-driven development using the Design Pattern Toolkit[END_REF]]. Transposed to SysML, a design pattern could be described as an internal block diagram, which comes with a sequence diagram. An activity diagram (functional view) and a state diagram (behavioral view) can be supplied. When an actual model is in the design phase, a part of it, revealing a design challenge, may require the application of a design pattern. Once the design pattern is chosen from a model repository by the domain expert who is currently working on this model, a pattern instance is parameterized with model entities involved (i.e. blocks, components, objects). As soon as the design pattern instance is applied to the model, the model entities are reconfigured to comply with the design pattern (their structure and composition may be amended, supplemented or renamed, constraints can be added). The process takes place as a local model modification: the latter mimics the design pattern applied. The design pattern instance persists within the model as a parameterized collaboration, and can be used at a later point (e.g. for the purposes of documentation).

UML has achieved a good level of formalization for software and analysis design patterns, based on class diagrams and object interaction diagrams. This paper aims to build upon this work to apply a similar approach adapted to the functional design of non software systems.

[Figure 2 here]

Function-block Languages

One of the problems is to fit a pattern language to a Systems Engineering language: eFFBD is a widely used formalism in SE [START_REF] Bock | UML 2 activity model support for Systems Engineering functional flow diagram[END_REF][START_REF] Vitech | CORE Architecture Definition Guide (DoDAF v1[END_REF]. An eFFBD (Enhanced Functional Flow Block Diagram) is a functional flowchart. An eFFBD can be considered as a superposition of an FFBD (Functional Flow Block Diagram) and a DFD (Data Flow Diagram) [START_REF] Long | Relationships between Common Graphical Representations in System Engineering[END_REF].

FFBD formalism has been used for a long time in Systems Engineering. It was developed in the 1950s by TRW Incorporated, and applied in the 1960s in the fields of aeronautics and space [START_REF] Blanchard | System Engineering and Analysis[END_REF]. It shows the functions of a system and their execution sequence, but does not mention data streams, whether single or triggering.

A DFD [START_REF] Demarco | Structured Analysis and System Specification[END_REF] represents system functions and the data flows processed by these functions, which absorb input data and produce output data after processing. The DFD does not represent the control structures that drive the activation and sequencing of the functions. An equivalent formalism is IDEF0 [Ross, DT & Brackett, JW, 1976], which refines the types of data streams by distinguishing inputs, outputs, mechanisms, and controls.

[Figure 3 here] Triggering data have control implications. Non triggering data are represented with a single arrow, while triggering data are designated with a double arrow. An eFFBD has an operational semantics allowing it to run as a discrete event model: a function must be validated (by the completion of the previous function execution in the control structure) and triggered (if a data entry is triggering data). The designer, therefore, has the ability to specify executing conditions of the functions, either by the use of control structures, or by triggering data, or a combination of the two semantics. The semantics of an eFFBD is completed by the notion of execution duration (min, max, average), as well as execution costs or resource constraints. [START_REF] Seidner | Formal Verification in System Design Process: from EFFBDs to Petri nets[END_REF] propose to translate eFFBD into Temporal Petri Nets [Petri, C., 1962].

This review of the literature does not reveal any form of design pattern well suited to functional architecture in the area of Systems Engineering. Adapting design patterns to SE (SE Patterns) begins by developing a supporting meta-model. SE patterns must be function oriented, thus such a meta-model has to include function graph structures. In a Systems Engineering perspective, functions compose operational scenarios, are allocated to components, and related to requirements which are themselves related to needs. Thus a minimalist Systems Engineering meta-model comes as an infrastructure for the SE Pattern meta-model.

Contribution

The goal of this section is to formalize patterns for Systems Engineering, going beyond the stage of textual documentation, by proposing a SE Pattern meta-model (Figure 2) extending a Systems Engineering meta-model (Figure 3). An example of a SE Pattern is then given as illustration (Figure 4). In the following subsections, terms in italics refer to entity names found in Figures 2, 3, and4.

SE Pattern meta-model

Our domain of interest is the representation of system engineering projects. A Project consists of several models each being a representation of the system under study and of a catalog which lists system patterns. A SystemPattern formally and informally identifies and documents a Solution addressing a Problem in a given Context that has been tested and deemed to be safe. These three concepts: Problem, Solution, Context, constitute a triangular pattern definition, which represents the core meaning of a SystemPattern. If any of the three elements is missing, this will result in a trivial pattern [START_REF] Gaffar | Semantics of a Pattern System[END_REF]. A SystemPattern is defined by at least the following characteristics: a unique identifier, a short but evocative name, alternative names as aliases, a creation date, a textual description and an author.

A Problem formally or informally describes the design problem motivating the SystemPattern.

Each SystemPattern addresses one and only one Problem. A Problem is characterized by an informal description, a Feature to be optimized, a set of competing Forces, a use case Model showing a trivial or a poor functional and/or organic architecture. A Force is a competing constraint in a System: design problems arise from a conflict between those different interests or "Forces". The SystemPattern application decision depends on arbitration between the Forces. [START_REF] Alexander | A pattern language: towns, buildings, construction[END_REF] gives the example of a conflict between the need for a sunny environment in a building, but not to be overheated in the summer. In this example, the Force is described by a challenge (the need for a sunny environment), a constraint (not to be overheated in the summer) and a ProblemType (Fluid, Field, Structure, Security...). A Feature is an extra functional characteristic, also named "-ilities" by [START_REF] Manola | Providing Systemic Properties (Ilities) and Quality of Service in Component-Based Systems[END_REF]: availability, maintainability, vulnerability, reliability, supportability…).

A Solution contains a pattern Model, which is a parameterized system architecture. It represents a design solution as a response to a Problem considering the given Context. There is only one solution for one pattern, but one Problem may have many solutions through several patterns by using equivalent-patterns and/or related-pattern relations. A Solution is illustrated by a use case showing a better architecture, resulting from the pattern application. The solution has an Impact that characterizes the influence of a SystemPattern on a model to which it applies. Impact(s) are quantified with a VariationSense (increase, decrease, equals) and a value on a scale. They are similar to post conditions, after a pattern is applied. The impact is measured on a feature. The Feature to optimize is often gained at the expense of another. For example, security may be improved (in this case the attribute variationSense of feature F1 is set to "increase") at the expense of manageability (the attribute variationSense of feature F2 is set to "decrease").

The Context expresses the core meaning of the pattern i.e. may be interpreted as a (set) of precondition(s). It indicates the situation to which the Solution may be applied, and the required conditions that must be checked before the pattern can be applied (informally, in the description attribute).

The other main relations between a SystemPattern and other concepts from the meta-model are:

• Since a SystemPattern is a parameterized architecture, each of its Parameters associates one of its own ModelElements to a ModelElement belonging to the model under work, e.g. Function, Component, Item, Interface, DataFlowConnection, Need, Scenario or Requirement.

• A SystemPattern is legitimated when mined in several well known applications (defined as knownUses).

• A requestedPattern is a SystemPattern required when applying a given SystemPattern. All requestedPatterns are also relatedPatterns.

• A relatedPattern is a SystemPattern, often present when a given pattern is applied. Within a triangular association Problem Context Solution, related patterns often have the same context, but relatedPatterns exclude antiPatterns.

• An antiPattern is in opposition with the SystemPattern of interest in a given case. Within a triangular association Problem Context Solution, anti patterns have the same problem and the same context.

• Equivalent patterns are patterns that have the same problem and the same context. In this case, the textual description may be more formalized in the solution/model/needs/description.

The Domain identifies a specific area in which a SystemPattern can be applied or is relevant e.g. mechanics, electronics, software, civil engineering, organization & service, security, pedagogy... The Rationale justifies the SystemPattern by an explicit description and the associated argumentation that justifies applying the pattern. It is different from knownUses in several Application, which are statistical observations. Problem, Solution, Context, Application and Rationale are Indexable objects, described by keywords.

[Figure 4 here]

Example of how an SE Pattern is Applied

The example in Figure 4 aims to show the SystemPattern instantiation application mechanisms (however it is a simplified example and is no a reference in the field of regulation).

The example shows a SystemPattern that is applied in three phases:

• The model under work in which there is the problem (A)

• The SE Pattern chosen to be applied (B)

• The model under work after the SE Pattern has been applied (C).

The three models are represented using eFFBD notation, which is supported by the meta-model shown in Figure 2 and Figure 3. These models could be transformed into SysML activity diagrams using the eFFBD profile, the two notations are isomorphic.

The Fx titled rectangles are system functions (Function meta-class), connected by a control flow

Model containing the problem (A)

The example of Figure 4 (A) shows a fragment of an industrial food process. Raw materials are placed in a container where a given environment is maintained, with parameters such as temperature and hygrometry. An air flow is provided by blowing air. The material to be processed is subjected to lactic fermentation, and also desiccation. The lactic fermentation is intended to provide the final product organoleptic qualities and to lower the pH to improve conservation. This process fragment is connected to a global process, which is not shown, by the maturation start entry link as well as by the maturation finished output link. It consists of four simultaneously active functions (and nodes before and after their parallel activity).

To achieve a goal of raw product maturation, four functions must work together:

• Contain: the raw product must be contained. The Contain function is fed by raw product and air stream. At the end of the process (refinement finished), the Contain function ends, and the processed raw product is outputted (refined product).

• The input flow (raw product) and the output flow (refined product) are discrete flow (path in the Figure 3 The problem in this model is one of incompleteness. To finalize this model, the Control Temperature function has to be decomposed. This function delivers a control data proportional to the difference between the residual heat output and the temperature profile setpoint so that the residual heat temperature reaches the setpoint.

Pattern solution (B): control-Command pattern semantics

The Control-Command pattern describes a regulation process in which an Actuate function delivers an effect output which is directed to an external function. This effect output modifies the external environment, of which, in return, one dimension is reinjected into the Measure function as the position Item. This pattern is a high level pattern, independent of the food processing area. It implements a control loop based on the feedback of the difference between a setpoint and a position, and the resulting action is proportional to that difference. This pattern (which is here a simplified version) is proven and recognized by all regulation experts [START_REF] Bennett | 1930[END_REF]) in various fields.

Pattern parameterization and application

A, B, and C models are described in

Pattern identification

This section is a brief discussion of pattern identification. This point is the second lock identified earlier in this article; it will be developed in a subsequent paper.

To be listed in catalogs, patterns must first be identified (mined) within models or systems in which they were applied, and where they are buried. Reverse engineering can also motivate the need for pattern identification. In order to identify buried patterns, models can be searched for within occurrences of particular identified patterns, in order to verify whether or not these patterns were applied. One can also look for any recurring structures, assuming they are patterns.

But then there is no evidence that they are not anti-patterns.

The difficulty lies, first of all, in the heterogeneity of notations and languages. In addition, MBSE techniques that facilitate model analysis are relatively recent and formal SE models have only been available for a few years.

Pattern mining techniques differ depending on whether the models to investigate are formal models (eFFBD, SysML, UML), for which there is a meta-model, or on the contrary textual or graphical unparsable models.

Product models, which are not SE models, but technical models, such as schematic diagrams or mechanical models produced by different computer aided design (CAD) tools, can also be analyzed to identify standard architectures.

In the case of older and less formal models, pattern recognition is done by experienced practitioners, who identify recurrent structures using reverse engineering processes. These patterns are then formally added to catalogs.

In the case of formal models, underpinned by meta-models, mining relies on techniques of subgraph recognition.

The matches are not exact: there will be similarities that will be measured. The techniques are those of model alignment [START_REF] Euzenat | Similarity-based ontology alignment in OWL-Lite[END_REF], [START_REF] Melnik | Similarity flooding: A versatile graph matching algorithm[END_REF]. Models to be aligned are, on one hand, models in which patterns are supposed to be buried, and on the other hand, pattern models from existing catalogs.

The alignment algorithms seek to match the entities of each model based on semantic similarities (names), obtained directly or indirectly through the use of glossaries or dictionaries, and also on structural similarities, seeking similar paths between similar nodes within two graphs under study [START_REF] Noy | Anchor-PROMPT: Using Non-Local Context for Semantic Matching[END_REF].

In the case of patterns based on functional notation such as SysML Activity Diagram or eFFBD, it will be necessary to construct graphs by transforming the functions or activities into nodes, and the control flow and data flow into edges. It will then be possible to apply the appropriate efficient alignment methods developed by the knowledge engineering community.

Conclusion

Systems Engineering conforms to the Model Based initiative [Estefan, J., 2008], and adopts languages and tools derived from those used by software engineering. However, design patterns, as understood in software engineering, are not adapted to the field of Systems Engineering.

Indeed, the SE approach should be a functional approach, and such patterns should be modeled as parameterized functional micro-architectures. This paper proposes to develop a specific approach for Systems Engineering, based on the eFFBD formalism which is widely used in this area. A meta-model that is interoperable with the main tools used by system architects has been designed.

Future work will consist in the following tasks: first, we will create an editor through which a catalog of System Patterns can be built, and develop mechanisms (based on model transformations) for applying patterns. Then, the presented approach will be developed to extend these System Patterns to allocation patterns that may help experts design better physical architectures. Finally, pattern detecting mechanisms based on model alignment will be implemented to complete the project.

Figure 1 :

 1 Figure 1: Systems Engineering Pattern Catalog

  Activities patterns -also described as systems engineering process patterns, indicate how the process of architecting or systems engineering is performed. 4. Systems Engineering Roles patterns -help describe how the architecting/engineering role is performed. 5. System Process patterns -capture how the system does what it does by using control loops, algorithms, etc. Cloutier's taxonomy seems to lack consistency due to a mixing of SOI patterns and SEA patterns: type 1 and type 2 are relevant to SOIs, type 3 and type 4 are relevant to SEAs, and type 5 is relevant to SOIs.

Figure 2 .

 2 Figure 2. A System Pattern Meta-model

Figure 3 .

 3 Figure 3. A Systems Engineering Meta-model

Figure 4 .

 4 Figure 4. Application of a System Pattern to an Incompletely Designed Model

(

  solid line) (ControlFlowConnection meta-class). The rounded rectangles represent the nature of the processed data flow (dashed line) (Item meta-class). The graph formed by the control flow and the functions is structured by control nodes (ControlFlowConnection and ConnectionType meta-classes). The model containing the problem (A) is an instance of the Model meta-class, associated with the Project meta-class by the modelUnderWork meta-association. When applying the pattern on the model (A) to produce the model (C), the original version (A) is preserved and remains accessible by the priorVersion meta-association. The SystemPattern model (B) is an instance of the Model meta-class, associated with the Solution meta-class by the patternModel meta-association.

  meta-model: DataFlowConnection, carries, Item, flow_type, discrete).• Flows as air stream, residual air stream, calorific energy, and residual heat are continuous flows (path in the Figure3meta-model: DataFlowConnection, carries, Item, flow_type, continuous).• Blow: This function converts electrical energy into an air stream. This outputted air stream is absorbed by the Contain function. The latter retransmits it as a residual air stream which is the input of the Blow function, and this is a closed circuit.• Heat: This function absorbs electrical energy to provide calorific energy. The latter is provided as input to the Contain function. The Heat function also consumes a given heating command. The latter is used by the function to modulate its calorific energy output.• Control Temperature: this function produces the heating command which will be absorbed by the Heat function. It absorbs a Contain output: residual heat, to compute, given the temperature profile and cycle mode inputs, the heating command output. This function also determines the end of the process. When all parameters are met (for example time * temperature * mass), this function ends and forces termination of the three remaining functions in the and parallel branch.

  Until the process represented by the model is not ended, Actuate and Measure functions are repeated in loop structures. Another cycle in this model consists of three sequential functions: Acquire Measure, Compute Command, Drive Actuator. The Acquire Measure function absorbs measured value data to transmit it after conversion as acquired measure to the Compute Command function. The Compute Command function compares a set point with acquired measure to issue a command output; command is fed into the Drive actuator function, together with a given energy, to produce a command to apply output. The latter is fed into the Actuate function that produces the effect as an output.

Figure 4 .

 4 The application of SystemPattern (B) to source model (A) containing the problem results in a transformation from the model (A) into a target model (C) containing the SystemPattern solution. The target model mimics the SystemPattern model. It is a parameterized collaboration of ModelElement. Some ModelElement belonging to model (A) will play given roles in the SystemPattern model (B). A model transformation taking as input model (A) to be corrected, model (B) to imitate, and the parameter list given in

Table 1 ,

 1 will produce the target model (C). Some elements of the SystemPattern model are renamed in the resulting target model. ModelElement related to Parameter has the names assigned to the concreteRole. Additional elements are renamed according to Table 2. Elements whose names are unchanged are shown in Table 3. Finally, one element, the ControlTemperature function, is removed after the SystemPattern is applied. Model (C) containing the solution provided by the SystemPattern (B) imitation is a reformulation of model (A) in which there is the problem. The overall function of model (C) is identical to that of model (A), but non-functional features are improved; namely, temperature control is optimized.

	Model containing the solution (C).
	ModelElement	Parameter patternRole	Parameter concreteRole
	ControlFlowConnection	process start	maturation start
	ControlFlowConnection	process end	maturation finished
	Function	Actuate	Heat
	Item	effect	calorific energy
	Item	position	residual heat
	Item	operational mode	cycle mode
	Item	command	heating command
	Item	set point	temperature profile
	Item	energy	electrical energy

Table 1 .

 1 System Pattern Parameters

	ModelElement	Name in SystemPattern	Name in model after pattern application
	Function	Acquire measure	Acquire temperature
	Function	Compute command	Compute heating
	Function	Drive actuator	Drive heating
	Function	Measure	Measure temperature
	Item	acquired measure	acquired temperature
	Item	command to apply	heating power
	Item	measured value	measured temperature

Table 2 .

 2 ModelElements added to Model (A) after Application of SystemPattern (B)

	ModelElement	Name
	Function	Contain
	Item	air stream
	Item	raw product
	Item	refined product
	Item	residual air stream

Table 3 .

 3 ModelElements Unchanged in Model (A) after Application of SystemPattern (B)