Cross-domain Methods and Tools for Decision Support Services ...

Cross-domain Methods and Tools for Decision Support Services based on Context Sensitivity Approach S. Scholze

D. Stokic, PhD, O. Kotte

ATB Bremen Wiener Str. 1 28359 Bremen, Germany [email protected]

ATB Bremen Wiener Str. 1 28359 Bremen, Germany

Abstract — Main objective of the paper is to create a generic methodology as well as context sensitive services based on an ontological approach, to support decision support across various application domains (e.g. manufacturing, software engineering). It is investigated how context sensitivity can be used in order to achieve high adaptivity of software solutions for decision support within the addressed application domains. This will result in realizing decision support services self-adaptable to the current identified context of users/products/services. The research will be driven by industrial application scenarios for decision support solutions for adapting of product extension services in several manufacturing companies in various sectors and for Quality Assurance of software development projects. Keywords — context sensitivity; decision support service; selfadaptivity; manufacturing; software quality assurance

I. INTRODUCTION The objective of the work presented in this paper is to investigate how context sensitivity can be used to achieve crossdomain decision support services for various systems. Key hypothesis is that the application of a new generic context sensitive solution can be used to realize cross-domain decision support systems (DSS). Moreover, the proposed approach assumes that the envisaged generic context sensitive solution can be easily adjusted to allow for adaptation of these systems. The application of context awareness in order to enable context sensitive systems and services ensures that changes in the circumstances under which a system is operating are observed properly. This in turn allows for appropriate adaptation and dynamic updating of the observed systems. To certify the applicability of the proposed approach, two disjunctive domains of application are addressed, where one scenario is dealing with complex manufacturing systems while the other is set in the domain of the area of (software) engineering. In order to facilitate applicability of the approach to wide scope of systems, the proposed solution builds on easily upgradeable and customizable features and components, including an extendable context model.

1

http://www.cs.cmu.edu/~anind/context.html

Putting such a novel context-aware solution, applicable to different scenarios and domains into practice requires a strong involvement of a powerful ICT-based infrastructure. The implementation of the complex parts of such a solution therefore needs to be focused on functionalities. Encapsulating functional features in separate modules with clearly defined scopes and finally orchestrating and combining these modules and functionalities by means of approaches for Service Oriented Architectures (SOA). Covering both, complex manufacturing systems as well as decision-making systems used in (software) engineering, is a challenging tasks where SOA principles are most appropriate. The paper is organized in the following way. Section II provides a brief overview of the state-of-the art. In Section III, the overall concept is elaborated. In Section IV, the applications of the proposed concept are briefly described, while in Section V plans for the future are indicated. II.

STATE OF THE ART

Context Awareness is a concept propagated in the domains of Ambient Intelligence (AmI) and ubiquitous computing. It is the idea that computers can be both sensitive and reactive, based on their environment. As context integrates different knowledge sources and binds knowledge to the user to guarantee that the understanding is consistent, context modeling is extensively investigated within Knowledge Management (KM) research. Using context information (for context-sensitive or ubiquitous computing) is an active area of research, with various context capture methods and context languages defined. Starting with the pioneering work at XEROX PARC [1], other notable frameworks are Context Toolkit (Berkeley)1, CAMELEON project2, C-OWL [2] and the Kimura System [3]. The current research on knowledge context is primarily oriented towards capturing and utilization of contextual data for actionable knowledge [4]. In addition, it has been shown that knowledge context could be used to classify and organize knowledge to realize unified management of distributed, heterogeneous knowledge in a networked enterprise [5]. However, such initiatives have specific goals, so an intense study of 2

http://giove.isti.cnr.it/projects/cameleon.html

collaborative work and its patterns is necessary to devise a suitable context model for collaborative decision-making. The overview of collaboration support systems and context-sensitive collaboration systems provided in [6] illustrates a lack in provision of knowledge context. A couple of systems to handle context awareness were proposed by the research community [7], [8], [9], [10] and [11]. By context modeling, the problem of how to represent the context information can be solved. However, how to extract context from the knowledge process and how to manipulate the information to meet the requirement of knowledge enrichment remains to be solved. In the research presented in this paper it is planned to model context with ontologies, and, therefore, context extraction mainly is an issue of context reasoning and context provisioning: how to infer high-level context information from low-level raw context data [20]. Based on the formal description of context information, context can be processed with contextual reasoning mechanisms [12], [13]. Defining context for applying context awareness can be difficult [14]. Informal context models are often based on proprietary representation schemes without facilities for sharing the understanding about context between different systems [15]. Existing formal context models support formality and address a certain level of context reasoning [16], [17]. The modeling of context in the case of decision support for Quality Assurance (QA) in software (SW) development process presents an additional challenge, as the services are highly dynamic and reside in distributed environments. In the case of services for monitoring, analyzing and enhancing software development processes and systems the notion of context refers to preferences and skills of users, physical capabilities of the equipment and environment conditions, coming from different kinds of information sources like bug-tracking systems, code repositories etc. Application of context awareness for SOA based software development processes and systems have not yet been sufficiently researched. With the emerging and maturing of semantic web technologies, Ontology based context modeling becomes a new trend both in academy and industry. Present research on context modeling is mostly focused on ontology. Compared to other methods, ontology based method has many advantages. Ontology allow context-modeling at a semantic level, establishing a common understanding of terms and meaning and enabling context sharing, reasoning and reuse [18] III. PROPOSED CONCEPT Services for context sensitive enhancement of knowledge in networked enterprises have been developed in previous research projects, addressing context model to support engineers performing maintenance tasks by reusing of existing (un-) structured company knowledge [19]. This approach for context awareness and context identification is partly used as a basis for the proposed context awareness approach, but it is adapted to the industrial QA software engineering targets. Based on the context awareness approach knowledge can be generated that is necessary to provide the envisaged decision support related to short-term operational decisions, which should be optimized regarding their effect on specific subtasks in software engineering processes, as well as long-term decisions related to the overall SW engineering process. The

proposed building blocks provide awareness about situations and based on this provide an appropriate support, presenting to the user only the key values and characteristics that really matter. The context awareness concept is presented in Fig. 1. Using Monitoring services, data on context of for instance SW engineering processes are collected. Monitoring Services try to observe changing conditions in either the systems’ or the users’ behavior by polling information or by being triggered. Therefore interfacing the available supporting tools and systems, present at each of the relevant stages in order to detect any event that may occur and gather any required data from the supporting tool’s databases is crucial. For SW Engineering these systems and tools can be for instance Issues Management tools such as TRAC or JIRA; Wikis, repositories or Content Management Systems such as Confluence, WikiMedia or Alfresco, etc. Obviously, the capturing of information about a manufacturing process or system can be carried out in the same way. Data are also collected from services managing social interaction (MSI). These MSI services are providing information and functionalities such as supporting communication, human resource discovery, team building etc. and are usually used within a collaborative decision making processes [21]. Based on all this data, the actual context is detected using Context Extractor (CE). CE maps the information provided from the MSI and Monitoring Services (using knowledge and context models stored in Knowledge repositories) onto the context model and thus finally provides the context. The detected context is provided to Enhancement services to support Decision making processes, either to influence a software engineering or a manufacturing process. On the top of that as indicated above, in outer loop using the user front end, the context model is updated based on the identified new concepts and relations.

Fig. 1. Context awareness concept

A. Context Model The purpose of the ontology is to define a fundamental data model for context extraction. As it is known, the discipline of knowledge management is not like knowledge engineering or artificial intelligence, it does not intend to answer questions such as how to build a knowledge base or how to realize automatic knowledge creation by reasoning, but tries to enhance computer as well as people during the knowledge process and handling of knowledge. The main purpose of KM is to provide the right knowledge to the right entity (be it services, devices, people etc.) at the right time. The ontology will be mainly used to model the systems engineering context and the different phases of the life

cycle as well as quality assurance aspects. Therefore, the ontology will not try to bring full description of context, but to index information to help to identify context. The ontology defines two ontologies: Generic Context Model and business-/sector-specific context ontology. Both Context Ontologies will model the knowledge context (including information of goal, activity, resource, etc.). As shown in Fig. 2, the ontology will be defined in such a way that it can be expanded: it is a layered ontology, with two parts, the generic part forms the core ontology and the business case specific part forms the domain/sector specific ontology.

Resource Description Framework (RDF) vocabularies and ontologies. For describing persons, their activities and their relations to other people and objects, the “Friend of a Friend” (FOAF)3 ontology will be used. Existing enhancements to the FOAF ontology like “Semantically-Interlinked Online Communities” (SIOC)4, “Simple Knowledge Organization System Reference” (SKOS)5 and “Description of a Project” (DOAP)6 were evaluated and re-used for the context model (w.r.t. software engineering). Several ontological concepts and properties from other European projects are interesting for the definition of the context model as well. B. Context Extraction The Context Extractor functionality can be divided into subgroups that collectively will characterize the service behavior as a whole. 1) Monitoring To be able to receive data from the interfaced Life Cycle Management (LCM) and Quality Assurance systems a monitoring component is part of the proposed solution. The Monitoring Service observe the external systems/tools docked into the solution to receive raw monitoring data. This raw monitored data will then be used for further processing and for context identification.

Fig. 2. Ontology extension approach (excerpt)

1) Context Modelling Some basic principles for context modelling were identified:  Support description of main context: In practice, we cannot model all context information, and besides, it is not realistic. The context model should consider those most relevant factors according to the requirement of context sensitive adoption.

2) Context Extraction Process The purpose of the Context Extractor is to extract context during daily operation and to provide the extracted context to the other services (such as the Enhancement Services). Fig. 3 shows the conceptual context extraction process.

 Model the context that is easy to acquire: Those context factors considered should be identifiable and acquirable, whether provided through computer monitoring automatically, or by user input explicitly.  Trade-off between investment of context modelling/extracting and effects of context sensitive adaptations: Intuitively, if we could model as much context factors in as much details, the accuracy of context will be higher. However, this does not come free. On the one hand, more time and efforts are needed on context modelling; on the other hand, more computing recourses are needed to handle the context, which will bring deficiency to the adaptation processes. According to these principles, and to the requirements of the business cases represented in the project, a first version of context model is developed, taking into account results from previous projects and of course other existing meta-models,

3 4

http://www.foaf-project.org/ http://sioc-project.org/

Fig. 3. Conceptual Context Extraction Process

There are three basic functionalities: context identification, context reasoning and context provisioning. Context identification harvests knowledge and knowledge context from the monitored information. Context reasoning deduces highlevel, implicit context from low-level, explicit context, and checks the context consistency and reliability as well. Context provisioning provides context for the other services, which would have to realize context sensitive adaptation whenever necessary. The extracted context (modelled as ontology instances) and the ontology itself will be stored in the context repository. 5 6

http://www.w3.org/2004/02/skos/ https://github.com/edumbill/doap/wiki

3) Context Identification Process There are two potential input sources for context identification: one is the monitored “raw data” provided by the machines; the other is by the user manually inputting knowledge context information. One of the reasons that existing knowledge management solutions do not work well in practice is because people are bothered too much to provide input manually. It will be a big burden for people to collect context manually. Therefore, the monitoring interfaces will provide as much context information as possible. They will monitor e.g. the states of testing platforms, issues in a bug tracking system, statistical analysis date coming from source code repositories (and the corresponding tools for generating those analytical data) or the status of devices involved in manufacturing a shoe, the current energy consumption of a robot on a shop floor etc. Finally, a set of “raw data”, structured for further context processing will be consolidated out of the monitoring process. In this way, the context identification process just needs to map the delivered data onto the ontology. Fig. 4 shows the conceptual Context Identification Process.

Fig. 4. Context Identification Process

However, it is possible that context could be provided by operators manually. Therefore, context identification could also provide interfaces for users to input context relevant information manually. A wizard-based solution might be used to help user represent the context accurately and input it into the proposed platform easily. 4) Context Reasoning With context identification, one can only acquire context information directly provided by monitoring interfaces or by the user. In some cases, this may not enough support for the other services for updating dashboards, thresholds, machine parameters, etc. For example, monitoring services and context identification in the first step might provide such context: a sensor indicates that a developed software module has some testing errors, which normally would indicate a critical event for the resulting product. However, what a context sensitive service might need to know is whether the testing error comes from wrong code or missing libraries or something else. There is a gap

1

http://clarkparsia.com/pellet/

between what context identification provides and what the other services may need. This gap could be closed by context reasoning. Based on the ontology definition and user defined domain specific rules, it can deduce indirect high-level, implicit context from direct lowlevel, explicit context. The core technology used here is deductive reasoning. Deductive reasoning is a basic technique in logics, in which conclusions (deductions) are reached by previously known facts (premises). Deduction is a wellunderstood general technique in general logics, and particularly relevant in logic programming. Since RDF and OWL will be used to model the ontology, deductive reasoning will be supported very well. Furthermore, also deductive reasoning will be used to check context consistency and reliability that might be brought in by imperfect monitoring. For example, the monitoring services might sense that “John Doe” is at the shop floor in a production facility and in the office at the same time. Obviously, this is impossible. The problem is that when inconsistent contexts exist, how is the project going to detect it and what should be trusted? Deductive reasoning can also help answer these questions. Therefore, two levels of deductive contextual reasoning can be distinguished: a) Ontological level At the ontological level, reasoning is possible based on the semantics of the ontology language (e.g. OWL) and the definitions in the ontology. For example, if the ontology defines "located-in" as a transitive relation, and Brussels to be "locatedin" Belgium, and the context data states that a particular development team is "located-in" Brussels, then deductive (transitive) reasoning would conclude that the development team is also "located-in" Belgium. Alternatively, as another example, if the ontology states that LISP is a subclass of functional programming language, and a particular company writes some pieces of code in LISP, deductive (subclass) reasoning would conclude that the company uses functional programming languages. b) Application level Application level reasoning uses the same deductive techniques but with application-specific rules. For example, a rule might specify that if a person is in an airport and the current time is working time then he should be travelling for business. Such application- or domain-specific rules could be provided by a domain expert or constructed based on a statistical analysis of historical data. Fig. 5 shows how the overall context reasoning process in the solution is realized. Any identified context can make use of ontological reasoning, rule based reasoning and reasoning based on other statistical measures. Whenever there was any reasoning applied to the initially identified context, the outcome of this process is a refined version of the initial context. Usually ontological reasoning comes almost for free when a so called Reasoner (such as Pellet7, FaCT++8) are used when querying the ontology and creating new instances, whereas there is some

2

http://owl.man.ac.uk/factplusplus/

domain expert required for creating rules for the rule based reasoning. Coming back to the LISP example from the ontological reasoning, with rules the system could reason that a certain piece of code written in LISP, which is classified as being a functional programming language, may be maintainable by staff members that have knowledge either in LISP (specific) or in another functional programming language (general). All the above-depictured reasoning steps are generally applicable but can also be skipped or not used at all.

TABLE I.

Main Area of Interest

Issues to be addressed

#1

Decision Support Services for quality requirements in distributed development teams Knowledge provision from previous customization projects

High variety of SW development projects varying in scope, duration, involving geographically distributed teams where the proposed approach is likely to support decision making by providing knowledge relevant for the specific context of the current SW development project Challenge is providing extensive services for the customization of its powerful SW product, is provision of knowledge from the previous customization projects which is relevant for the context of the current project and decision making process Configuration & simulation services to be used in complex internal supply chains to develop personalised PES. Adding AmI features, context extraction and knowledge provision services on product use important for vehicles. Embedded services, adding AmI features privacy issues related to context extraction; reengineering of manufacturing process for extended products

#2

#3

Fig. 5. Context Reasoning Process

#4

5) Context Provisioning Context provisioning provides context information for the services to realize context based adaption. The key is to provide right context to the right service in the right granularity at the right time. Right context means just the context information that is needed, no more or no less; right granularity means not too detailed or not too abstract; right time means only provide when it is needed. Context could be provided proactively (proactive context provisioning) or based on the request of the services (on demand context provisioning). With proactive context provisioning, the services should be notified automatically when context changes; with on demand context provisioning, context will be provided only when the services issue a request. Since the semantic web ontology language OWL will be used to build the ontology, SPARQL provides a good mechanism to support context provisioning. SPARQL is a SQLlike language for querying RDF data. SPARQL can be used to express queries across diverse data sources, whether the data is stored natively as RDF or viewed as RDF via middleware. SPARQL contains capabilities for querying required and optional graph patterns along with their conjunctions and disjunctions. SPARQL also supports extensible value testing and constraining queries by source RDF graph. The results of SPARQL queries can be result sets or RDF graphs and thus be fed back to other modules and components of the platform that require contextual information for further processing. IV. APPLICATION In this section, the application of the proposed approach is detailed. The proposed platform and services are currently under development and testing. The approach is assessed in two different business domains in order to validate the results in different conditions. The assessment is carried out in several application scenarios as described in the following table.

ISSUES TO BE ADDRESSED BY THE PROPOSED APPROACH

App. Scen.

#5

Personalised support to drivers to optimise energy use (classical, hybrid and electrical cars) Services to support remote condition based maintenance of home appliances Services for personalised design and manufacturing of new shoes

Services around machines to effectively produce personalised shoes; upgrade of machines with AmI technology for easier adaptation; optimise eco aspects of urban manufacturing related to high variability of customised; context modelling & data collection within machines manufacturing processes

Two different application scenarios are described in more detail in the following sub section. A. Application in Software Industry The first application domain belongs to software development industry. This industry is characterized by high variety of SW development projects varying in scope, duration, involving geographically distributed teams where the proposed approach is likely to support decision making by providing knowledge relevant for the specific context of the current SW development project. Various collaborative decision-making process are supported. One of the typical examples is negotiation on SW quality requirements and targeted value. The geographically distributed experts negotiate on the relevance of various requirements where Enhancement services suggest weighting based on the identified context under which the decision process is carried out. Analytical services analyze the situation, based on the identified context, and identify requirements/weighting used in the previous ‘similar’ project, provide them to the Enhancement services. MSI services support collaborative work (i.e. identification of experts needed for negation session). Another case where the proposed approach is applied deals with provision of knowledge from the previous customization projects, which is relevant for the context of the current project and decision making process (e.g. how problems were solved in previous projects under ‘similar’ context). In both cases software engineers, developers and testers will be able to rapidly correct inadequate trends in design,

development and testing, project managers will be able to schedule deliveries with the agreed level of quality and IT managers will be able to forecast and make decisions on how to reduce the cost and increase quality of future projects. This will introduce a high level of automation in the Software Quality Management process avoiding the traditional problems of data gathering and analysis in traditional QA. B. Application in Manufacturing Industry The second application domain addresses the extension of machines with new services to allow for provision of highly personalized products and effective customization. One example of such application is to allow consumer to design customized shoes and to produce such customized shoes on customers demand. To support such approach (by provision of context sensitive data needed for collaborative work and decision support with geographically distributed teams) and in order to allow customer driven shoe production and so called “urban manufacturing”, there is a need for radical change in their automated production systems. Therefore, it is intended to apply intelligent services and to make intensive use of information from context sensitivity integrated in their machines. The involved company intends to extend the machines with new advanced context sensitive solutions (e.g. for effective interaction between the operator and machines) needed for urban manufacturing of personalized shoes. The most challenging problems in this example scenario, represents the required customizability of machines and services to allow the production of machines, which are able to satisfy the vision of consumer driven shoe production. V. CONCLUSION AND FUTURE WORK The proposed approach and services are currently under development and testing. The approach is assessed in several scenarios within two different business domains in order to validate the results in different conditions. The applicability in diverse application domains, such as software industry and manufacturing industry is demonstrated. The relatively clearly indicated directions of further system improvements allow for optimistic expectations regarding future system applicability. A Key future research topics, as it can be seen from application scenario “Application in Software Industry”, is further investigation of additional reasoning capabilities of semantically related subjects, i.e. of precisely structured application specific ontologies. Future research will therefore focus on better generic context model as well as better support for domain specific adaptations. In addition, it will be researched how domain specific models can be automatically updated by using context sensitive feedback on usage. It will also be researched how to generalize automatically updated context models, in order to feed updates of the specific models back to the generic model. ACKNOWLEDGMENT This work is partly supported by the ProSEco and UQASAR projects of European Union’s 7th Framework Program, under the grant agreement no. NMP2-LA-2013-609143 and ICT-FP7-318082. This document does not represent the opinion

of the European Community, and the European Community is not responsible for any use that might be made of its content. REFERENCES [1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12] [13]

[14] [15]

[16]

[17]

[18]

[19]

[20] [21]

Weiser, M., Gold, R. and Brown, J.S., The origins of ubiquitous computing research at PARC in the late 1980s. IBM Systems Journal 38(4), 1999, pp. 693-696 Bouquet, P., Giunchiglia, F., van Harmelen, F., Serafini, L., Stuckenschmidt, H., C-OWL: Contextualizing Ontologies, Lecture Notes in Computer Science Volume 2870, 2003, pp 164-179 Voida, Stephen and Mynatt, Elizabeth D. and MacIntyre, Blair and Corso, Gregory M., Integrating Virtual and Physical Context to Support Knowledge Workers, IEEE Pervasive Computing archive, Volume 1 Issue 3, July 2002, pp.73-79 Mladenić, D., Active Project Website., Retrieved January 10th, 2012, from http://www.activeproject.eu/fileadmin/public_documents/D231_context_definition_and_re presentation.pdf, (2009) Tao, Y., Tianyuan, X., Linxuan, Z., Context-centered design knowledge management, Computer Integrated Manufacturing Systems, 10 (2004), 1541-1545. Ahn, H. J., Lee, H. J., Cho, K., & Park, S. J., Utilizing knowledge context in virtual collaborative work, Decision Support Systems, 39(2005), 563582. Bellavista, P., Corradi, A., Montanari, R., Toninelli, A., Context-aware semantic discovery for next generation mobile systems, IEEE Communications Magazine, 44 (2006), 62-71. Toninelli, A., Corradi, A., Montanari, A., Semantic-based discovery to support mobile context-aware service access, Computer Communications , 31 (2008), 935-949. Gu, T., Pung, H. K., Zhang, D. Q., A service-oriented middleware for building context-aware services, Journal of Network and Computer Applications, 28(2005), 1-18 Kim, S., Suh, E., Yoo, K., A study of context inference for Web based information systems, Electronic Commerce Research and Applications 6(2007), 146-158. Chang, J. W., Kim, Y. W., Design and implementation of middleware and context server for context awareness, High Performance Computing and Communications, Proceedings, LNCS 4208(2006), 487-494. Luther, M., et al., Situational reasoning – a practical OWL use case. Chengdu, Jiuzhaigou, China, 2005. Forstadius, J., Lassila, O., Seppänen, T., RDF-Based Model for ContextAware Reasoning in Rich Service Environment, Proceedings of the Third IEEE International Conference on Pervasive Computing and Communications Workshops. IEEE Computer Society, (2005) Dey, A.K ., Understanding and Using Context. Personal and Ubiquitous Computing Journal, 1(2001), 4-7. Kindberg, T., et al., People, places, things: Web presence for the real world, Third IEEE Workshop on Mobile Computing Systems and Applications, (2000). Henricksen, K., J. Indulska, and A. Rakotonirainy, Modeling Context Information in Pervasive Computing Systems, Pervasive Computing, (2002), 79. Ranganathan, A., Campbell, R.H.. A middleware for context-aware agents in ubiquitous computing environments. Springer-Verlag, Rio de Janeiro, Brazil, 2003. Georgalas, N., et al. Towards a Model-Driven Approach for OntologyBased Context-Aware Application Development: A Case Study. In: MOMPES ‘07. Fourth International Workshop on Model-Based Methodologies for Pervasive and Embedded Software, 2007. Ziplies, S., Scholze, S., Stokic, D., Krone, K., Service-based Knowledge Monitoring of Collaborative Environments for User-context Sensitive Enhancement, ICE-2009, 2009. Scholze, S., Stokic, D., Barata, J., Decker, C., Context Extraction for SelfLearning Production Systems, INDIN 2012, Beijing, 2012 Campos, A.R., Intelligent Decision Support Systems for Collaboration in Industrial Plants, PhD., Uninova, Lisbon, 2010.