Using knowledge and expressions to validate inter-model constraints

Transcription

1 Using knowledge and expressions to validate inter-model constraints David Simon Zayas*. Anne Monceaux*. Yamine Ait-Ameur** *EADS Innovation Works, Toulouse, FRANCE ( s: **LISI/ENSMA, Futuroscope, FRANCE ( yamine@ensma.fr) Abstract: Model Based System Engineering (MBSE) field recommends practices, framework, tools and standards to improve the modeling of systems. Nevertheless, even though one follows a modeling methodology, inconsistencies arise in models since they are shared and developed in a collaborative context. This paper focuses on an approach to manage models heterogeneity by taking into consideration the implicit knowledge of the engineers. We defend this knowledge as the key to check inter-model constraints in the framework of MBSE methodologies. Keywords: Systems engineering; Interoperability; Concurrent Engineering; Models 1. INTRODUCTION Big mechatronic systems such as aircrafts are developed within large and complicated organizational structures which involve many teams of large enterprises and their supplier networks, and their development life cycle is several years long. It is a fact that the necessary work sharing and collaboration between multiple actors over time always result in a multiplicity of local problems and viewpoints. During the design phases, the aircraft system is represented by a number of models, each bounded to some given sub-system or viewpoint, and each valid at some given moment of the design progress. We focus on descriptive and prescriptive models of a system, i.e. the artifacts used during the descending part of the V- lifecycle. A model represents sub-system context and interfaces, internal structure and behavior. Models are developed independently on the basis of specifications and requirements, but from a validation and verification (V&V) perspective they might need to be integrated someway or at least verified or validated from an integrative perspective. System engineers use various modeling languages that include graphical formalisms to produce several views or diagrams, coupled with execution capabilities. Many research works in Model Driven Architecture (MDA) and Model Based System Engineering (MBSE) fields deal with model heterogeneity related to the use of different modeling languages or paradigms or of different data standards, which might lead to models interoperability or consistency issues. Moreover we are also interested in less formal consistency issues that grow from the same root causes (the segmentation and distribution of the design and modeling work) but are related to other variability observed in: The models coverage; overlap of models or gaps in the modeling coverage exist because each single model is a closed simplified representation to solve a local problem. The way the sub-systems context and boundaries are defined. The use of different terminology depending on domains and engineering teams. The models maturity status. The development of complex systems is not a one-shot activity but a recurrent process which goes from conceptual design to detailed design. Therefore, models evolve and have different degrees of maturity along the development cycle which may lead to temporary consistency problems. This particularity has to be taken into consideration when validating a model. Section 1 includes this introduction and some background about Systems Engineering methodologies, models and the use of knowledge. Section 2 describes the case study to be used during the explanation of our approach in Section 3. In the end, Section 4 presents some conclusions and future work. 1.1 Standards and Processes Many Systems Engineering (SE) standards have been developed in the last forty years. In (Estefan 2008) and (Monzón 2010), authors give an overview of the different SE methodologies and standards and their temporal evolution. The (ISO 2008) standard is reasserted in the recent INCOSE Systems Engineering Handbook (Haskins et al. 2010) as the currently most complete industrial norm. Following lines summarize the first technical processes of this standard applied during the descending part of the classical System V- lifecycle; we will later refer to them in the rest of our article in order to set our case study in a methodology perspective: Copyright by the International Federation of Automatic Control (IFAC) 2737

2 Stakeholder Requirements Definition Process. Definition of the system from an operation point of view: the stakeholders -including customers - requirements are elicited, the operational scenarios are described and the context of use of the system is identified and analyzed. Requirement Analysis Process. Analysis of the system as a black-box, characterizing the technical requirements that fulfill the stakeholder requirements. The functions and the functional architecture are outcomes of this process. Architectural Design Process. In a first step, it consists of the tasks that lead to a logical organization of the system by optimizing the use of internal interfaces. It is an abstraction of a possible physical architecture. The final step in this development process is to match the logical architecture to the best physical architecture. It implies usually some trade-off studies to choose the best physical architecture. As a final result we obtain: logical architecture and internal interfaces (between logical groups); external interfaces detail; the allocation of system requirements to operators; and the specification of the selected physical design solution. The description of the system architecture is an input to more detailed development activities which apply recursively the same processes -if appropriated and necessary based on the level of detail. 1.2 Models and Methods System engineers use graphical modeling languages to design and specify systems. In our context SysML and CORE language (Long 2000), among others, are used. Associated guidelines recommend the modeling constructs and the diagrams that should be used in each technical process. For example, (Vitech Corporation 2005) guide for Systems Engineering gives modeling recommendations using the CORE language and environment. For instance, they suggest modeling elements e.g. the use of Link to refine an Interface- and diagrams e.g. Physical Block Diagram to connect Components through Links- to be used in the Architectural Design Process corresponding activities. In a similar way, largely inspired on the aforementioned ISO standard, INCOSE has evolved the Object Oriented Systems Engineering Method (OOSEM) (Lykins et al. 1999). OOSEM is a method originally conceived by the Software Productivity Consortium in collaboration with Lockheed Martin Corporation. The first versions of the method were UML oriented until the participation of INCOSE reoriented it to use the SysML language (Friedenthal et al. 2008). As an example of guideline, the method recommends the use of Internal Block Diagrams (IBD) in order to describe the exchanges between Blocks. OOSEM is technically a method since they do not impose any particular tool; Rhapsody is one possible implementation choice in industry. 1.3 Implicit knowledge Previous sections illustrated how heterogeneity also relates to the applied modeling method and language and to the achieved process stage or technical process. We now present another factor for heterogeneity which may, paradoxically, be used at the same time to reduce it, as we will see in our approach description. It concerns the implicit knowledge managed by an engineer or a team, which is common in their context. Such implicit knowledge is usually not included in models although it is a key factor to understand them when they are shared or analyzed as a whole. As discussed in the case study of section 2, an example of this kind of implicit knowledge can be found in a scenario such as one engineering team designs the avionics system, i.e. critical domain systems, whereas a different team models non-critical aircraft software. None of the teams indicates the domain of their models since it is obvious for them; nevertheless this knowledge is crucial when both models are checked jointly, since different constraints apply to them. Another case arises when engineers name the same element using different words in their respective models. This can be due to incomplete specifications or to the evolution of the models themselves -e.g. an interface has changed of name and only one team is aware of this amendment whereas another team still uses the old name-. In such cases a management and use of common knowledge prove to be necessary. Depending on the complexity of knowledge to be treated, different techniques or tools can be applied: a common dictionary, taxonomies or ontologies. As an example, in (Oliveira et al. 2009) authors suggest the use of ontologies to compare models. As we will see later, our approach recommends annotating models in order to make explicit the needed knowledge. 2. CASE STUDY In section 1.2 we have sketched two similar methodologies using different modeling languages: CORE and SysML. Now we are going to analyze some elements of two models which are the result of applying these best practices. The CORE model is about the Shared Information System (SIS) and describes the non-critical software of the aircraft. The SysML model presents the aircraft critical software, the Cockpit Information System (CIS). Our case study is set during the Architectural Design Process presented in Section 1.1. The models must be interconnected and some general constraints need to be checked before passing to the next design phase, i.e. before repeating the process from the beginning to achieve a more detailed design. On one side a Physical Block Diagram, see Fig. 1, describes the component which transfers maintenance messages (Items) through a Link. On the other side a BDD diagram shown in Fig. 2 represents the subsystem generating maintenance messages that are sent to SIS. Moreover, a general implicit constraint says that every communication from a critical domain system to a non-critical domain one shall implement a protocol considered as secure. 2738

3 The engineer in charge of the development chooses the elements of the models to be exported to the common framework. Figure 1. Physical Block Diagram representing the communications, Link, from a subsystem to an external system. The annotation step introduces the explicit knowledge to enrich the models with extraknowledge usually not formalized in such development models. This annotation process can be directly achieved by the engineer itself or by the modelers themselves as part of their modeling activity. Moreover, some annotations may exist from previous applications of the method and they may be reused or be the starting point for defining new annotations. Next step consists of setting the inter-model relations. Nevertheless, some relations may be inferred if appropriate knowledge rules are defined. Figure 2. Block Definition Diagram showing external interfaces. In this case, necessary knowledge but however not contained in the models is: 1) domain of the components, i.e. whether they are in a critical or a non-critical domain; 2) the concept of message depending on the used modeling language; and 3) the name of the authorized communication protocols which are X.25 and Encrypted Ethernet. 3. OUR APPROACH In (Simon Zayas et al. 2010) we introduced a method which suggests using knowledge to check constraints over heterogeneous models. The idea of the method is to export the elements of the models we want to work with to a unified and shared modeling language, which is used to write the meta-models of the different original modeling elements. Secondly, the exported elements are annotated to incorporate the implicit knowledge. Then, all this information is taken into consideration to set up the inter-model relations. Finally, common constraints are formalized and checked over them. The engineer in charge of the development selects or builds the inter-model constraints that he or she wants to validate. In a Systems Engineering methodology some of these constraints, if not all, should be defined as part of the process. In such a case we expect the availability of catalog of constraints which could be set up for each specific development use case or template. At this step, the engineer in charge of the development is ready to check the constraints and analyze the results in order to notify to the modelers the eventual modifications This process is iterated until the validation of the whole constraints is guaranteed. All the validation should be checked after a modification, indeed, this development is not monotonic and some design decision could be discussed after the possible modifications (analysis of impact). 3.1 Exportation and annotation principles Fig. 3 illustrates the meta-classes that we have defined to enable the exportation of original model elements and their relationship with the entities needed to add knowledge. Our goal is to apply this approach to support a Systems Engineering methodology, specifically when the engineer designing a system needs to guarantee the correctness of models before switching from a development step to the next one, e.g. from Requirement Analysis step to Architectural Design step. This approach aims at strengthening the cross model verification and validation activities. During these checkpoints, also known as maturity gates, the different models, resulting of the concurrent engineering activities, should be put together to verify the consistency of the design before continuing. In this context one of the possible use cases would be: Figure 3. UML diagram of relevant meta-model classes. 2739

4 EntityClass represents the basic element of models. One EntityClass can have multiple attributes represented by the AttributeClass. We can extend AttributeClass with the types that we consider necessary, the figure shows the most basic ones. One particular kind of attribute is the EntityAttributeClass, used to model the relationships amongst EntityClass. In our case study these entities are used all along the exportation as follows: SIS model. Link ( extcomm in Fig. 1) and Item classes inherit from EntityClass to form Link and Item_Core respectively. Their attributes extend AttributeClass according to their type, for instance the name of the Link is a StringAttributeClass called LinkNameAttributeClass whose value is extcomm. Thus, when exporting the SIS model, instances of the original model are converted into instances of Link and Item and of their attributes. CIS model. In order to export the SysML classes, EntityClass and AttributeClass are similarly extended to build up Block. Once again, the export activity consists of instantiating the SysML instances in the new common language. E.g., NCSystem in Fig. 2 would be an instance of Block. Concerning the annotation step, many studies are performed about annotation techniques but fewer concern the annotation of models. Some interesting work in the area of enterprise modeling. (Zouggar et al. 2008) suggests linking elements of the models to concepts of an ontology whereas (Boudjlida & Panetto 2008) describe a more complex framework with different ways and types of annotations depending on the kind of interoperability issue. In general, annotations are written by domain experts, but some systems like A* (Athena Project 2006) intends to provide some semi-automatic annotations. A platform with the capability to infer some annotations, always under the supervision of experts in order to guarantee a maximal degree of consistency, can be envisaged. At the current stage of our work, annotations are associated to the entities of the models, in order to be capable to exploit them in defining cross models constraint expressions that may involve concepts issued from different heterogeneous models. EntityClass may be connected to one or more pieces of knowledge via the AnnotationClass. One AnnotationClass links to one or more unique identifier/s (URI) which is/are also modeled by a meta-class. URI precisely identifies an element of our knowledge base which is an instance of KnowledgeClass. The other way round is also possible, i.e. one KnowledgeClass can be related to more than one EntityClass. A short example illustrates the use of this meta-model. Indeed, in SIS model, Link connects to one AnnotationClass to make explicit the type of communication protocol; we can see a detail of the related instances in Fig. 4. In some cases several entities might be annotated with one AnnotationClass instance, for example if several Items in a CORE model together compose a message, while in a SysML model (see Fig.3), only the Parameter of the receivemessage Operation of ExternalCommunication Interface corresponds to this message. The different Item instances will be connected to one AnnotationClass instance representing the message concept, to which the Parameter instance is also related. //Model element #39=ITEM_CORE_NEW(#27, #28, $, #29, #30, #31, #32, #33, #34, #35, #36, #37, #38); #49=LINK_CORE_TRANSFERS_ATTRIBUTE_CLASS( (#13,#39,#26)); #50=LINK((#118), #40, #41, #42, #43, #44, #45, #46, #47, #48, #49); //Annotation entity #118=ANNOTATION_CLASS('protocol', (#115)); //Knowledge base #106=COMMUNICATION_IS_SECURE_ATTRIBUTE_CLASS(.T.); #108=COMMUNICATION_IS_SECURE_ATTRIBUTE_CLASS(.F.); #109=COMMUNICATION_PROTOCOL_NAME_ATTRIBUTE_CLASS( 'EX25'); #111=COMMUNICATION_PROTOCOL_NAME_ATTRIBUTE_CLASS( 'X25'); #112=COMMUNICATION_PROTOCOL_NEW( #115, #109, #106); #114=COMMUNICATION_PROTOCOL_NEW( #117, #111, #108); #115=URI(' #117=URI(' Figure 4. Annotation of communication protocol. 3.2 Expressions/Constraints The main goal of our method is to ease the check of constraints affecting more than one model with support of implicit knowledge. As a consequence, we need a means to express these constraints considering both model entities and knowledge. This capacity must be flexible enough since we can have very different kinds of models and constraints. We have decided to formalize our own expression language by firstly defining a grammar. The goal of this grammar is to clearly identify the type of expressions that we can use in the constraints. The grammar, formalized in the Backus Naur Form (BNF (Naur 1960)) is based on the PLIB (ISO 1997) expressions language proposal. Even though the problem we deal with is not the components and parts library modelling which is the core of PLIB, its approach allows us to build expressions in a structured and easily extendible way that fitted our needs to build a proof of concept. Thus, the original proposal has been reinforced with mainly First Order Logic concepts in order to fulfill our logical constraint expressions needs. After setting up the grammar, we have developed a model that covers it. On one side, the model contains elements representing implicit semantics, i.e. logical expressions whose meaning is universally accepted, like the FOL part shown on Fig. 5. As we can see, FOL expressions have been defined as a new type of BOOLEAN_EXPRESSION. Thus, one FOL expression consists of a set of variables which must fulfill another BOOLEAN_EXPRESSION (the predicate). 2740

5 l : Link ( l Y. comprised _ of ) i : ( o o : Operation _ UML p : cp : Communicat ion _ Pr otocol l ( i ( { } )) l. transfer ) i represents = Z. owned _ operation ) ( _ UML ( p o. owned _ parameter ) p{ represents } = Z ) ) ( cp.sec urised = TRUE ) Item X Parameter { protocol } = cp X { protocol } = cp (1) expresses the constraint to be checked where Y is a CORE Interface; X is the related (inter-model relation) SysML Interface and Z is the knowledge item representing a message. Concerning the variables: l are the CORE Links comprised in Y; i are the CORE Items transferred by l; o are the SysML Operations owned by X; p are the SysML parameters of o; and cp are the communication protocols defined in our knowledge base. (1) Figure 5. Excerpt of expressions structure in a UML diagram. On the other side we need to cover explicit semantics. This is the role of variables since their meaning depends on the entity they refer to. As shown on Fig. 6, variables can contain elemental types as String (STRING_VARIABLE), Boolean (BOOLEAN_VARIABLE) and Numeric (NUMERIC_VARIABLE), but also more complex structures. In our case we define complex variables representing a path to entities and to attributes of models. For the sake of simplicity we are going to detail one part of this expression. (( i l. transfer ( i{ represents } Z )) i : Item ) = (2) Fig. 7 illustrates expression (2) as a logical tree according to our grammar. Therefore the first element is an EXISTS_EXPRESSION which is built from one ENTITY_VARIABLE (i:item) and one BOOLEAN_EXPRESSION; the AND_EXPRESSION (^). Then the AND_EXPRESSION is derived until arriving, in a depth-first order path, to the leave items: i, l.transfer, i{represents} and Z. Please note that we have used an ad-hoc notation to indicate the access to the related knowledge, thus i{represents} is interpreted as the annotation named represents which is connected to the entity Item represented by i. Figure 6. View of variables model in UML. Example of use In order to describe the use of expressions, let s take our case study. As we have mentioned, we need to check that every communication from a critical domain system to a noncritical domain one shall implement a protocol considered as secure. From a logic point of view, we can express this constraint for the elements of the study case as: Figure 7. Logical tree illustrating the expression. 3.3 Experimentation In order to implement our approach we have used EXPRESS (ISO 1994). EXPRESS is a modeling language which allows defining models and checking constraints in a same notation 2741

6 and environment. This versatility has made of EXPRESS our choice as common language to experiment our method. Thus, the entities concerning exportation and annotation and the expression model have been implemented using the ECCO toolkit (PDTec GmbH 1998) which includes an EXPRESS editor and a constraint checker. Nevertheless, our layered approach allows the use of different combined languages and, for example, we could implement the expressions model in a different one. 4. CONCLUSIONS Interoperability between systems begins at early-design phases. In the context of Systems Engineering design methodologies, engineers need to work with models from different teams, methodologies and savoir-faire. Models are a tool of cooperation which can ease the interoperability of the systems to be designed. We have defined a method to use knowledge and to define expressions with a flexible language in order to check constraints over inter-model relations. We suggest applying our approach as part of the validations to perform inside Systems Engineering methodologies. Particularly, our method is suitable in a collaborative context when we put together and validate some of the models of the current design stage to guarantee the quality of the input for the next stage. Our approach main advantages are that implicit knowledge can be formalized and that the use of aside models allows keeping the original models unchanged and eases the traceability from the checked constraint to the involved source elements. Nevertheless, there is a risk of loss of data during the importation of source models. In our example this issue is minimized by the use of object-oriented languages in both source and target meta-models but the impact of other kind of modeling languages should be studied. Furthermore, more industrial examples must be analyzed to delimit the scope of applicability of the approach and the level of automation of annotations, to evaluate the user effort/benefit ratio of the method appliance and to take into consideration the evolution of models and of annotations. Currently, we are analyzing different modeling methodologies and models in order to extract some general inter-model relation constraints for the design activities described in our introduction. Our on-going activities include the definition of knowledge and rules to suggest annotations of models and to infer relations between models. Finally, a prototype is being developed to validate our approach with industrial examples. REFERENCES Athena Project (2006) Semantic Annotation language and tool for Information and Business Processes Apendix F: User Manual., pp Boudjlida, N. & Panetto, H. (2008) Annotation of Enterprise Models for Interoperability Purposes. In IEEE IWAISE'2008. IEEE. Estefan, J.A. (2008) Survey of Model-Based Systems Engineering (MBSE) Methodologies. Available at: pdf. Friedenthal, S., Moore, A. & Steiner, R. (2008) A Practical Guide to SysML - The Systems Modeling Language, Morgan Kaufmann OMG Press. Haskins, C., Forsberg, K., Krueger, M., Walden, D. & Hamelin, R.D. (2010) SYSTEMS ENGINEERING HANDBOOK, INCOSE. ISO (1994) ISO , International Organization for Standardization. ISO (1997) ISO , International Organization for Standardization. ISO (2008) ISO/IEC 15288:2008, International Organization for Standardization. Long, J. (2000) Relationships between Common Graphical Representations in System Engineering. Available at: information/reference/paper_j-long-commongraphical- Notation-in-SE-2002.pdf. Lykins, H., Ave, N.F. & Meilich, A. (1999) Adapting UML for an Object Oriented Systems Engineering Method ( OOSEM ). In Proceedings of the 10th International INCOSE Symposium. Monzón, A. (2010) Bi-directional Mapping between CMMI and INCOSE SE Handbook. In ERTS². Toulouse. Naur, P. (1960) Revised Report on the Algorithmic Language ALGOL 60. In Communications of the ACM, Vol. 3. pp Oliveira, K., Breitman, K. & Oliveira, T. (2009) Ontology Aided Model Comparison. In 14th IEEE International Conference on Engineering of Complex Computer Systems. PDTec GmbH (1998) ECCO Toolkit, Karlsruhe: PDTec GmbH. Simon Zayas, D., Ait-Ameur, Y. & Monceaux, A. (2010) Knowledge models to reduce the gap between heterogeneous models Application to aircraft systems engineering. In ICECCS IEEE. Vitech Corporation (2005) Systems Engineering Guided Tour, Vitech Corporation. Zouggar, N., Vallespir, B. & Chen, D. (2008) Semantic Enrichment of Enterprise Models. In IEEE IWEI IEEE. 2742