Introduction

Risk is an ever present element in the daily operation of many organisations throughout the world. Success, profitability, competitive advantage and survival all depend upon an organisation’s ability to focus upon risk, then assess and derive the best course of action relative to their specific domain of operation and operating requirements. Many organisations are seeking ever better ways to conduct and grow their business, the servitisation of products, i.e. the combination of products and services into one offering (Vandermerwe and Rada 1988), is something that is becoming ever more popular and hence, the provision of Product-Service Systems (PSS). Organisations need to change traditional approaches to undertaking business, they must become more agile, more sensitive to the pace of change and aware of other factors that influence their operations, not just locally, but globally too. This applies to aspects such as the technological rate of change, economic issues and environmental sustainability and impact (Doualle et al. 2015; Hussain et al. 2016; Medini and Boucher 2016; Schmidt et al. 2015; Sousa-Zomer and Miguel 2016). Evermore legislation is being enforced both at national and global levels to promote and influence attitudes towards the environment and sustainability. When designing, developing and producing PSS for customers, many organisations interact and cooperate with numerous other organisations. Thus, to all intents and purposes they can be classed in some shape or form as collaborative networked organisations (CNO) as put forward by Camarinha-Matos (2009) and Camarinha-Matos et al. (2009). One key enabling factor that underlies CNO is that of interoperability, i.e., “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” (IEEE Std. 610, 1990). To date, the issue and facilitation of interoperability for organisations still consumes large amounts of time and money (Brunnermeier and Martin 2002; European Commission 2008; Sampath and Hegde 2013; Huber 2014). Hence, to be able to deploy such an approach more quickly than competitors can often be a significant advantage, therefore, the development of approaches and technologies to achieve this can be of great importance. One domain where these can be applicable to and potentially derive benefit for organisations by enabling them to lower costs, adapt better to change and adopt technology faster is that of Global Production Networks (GPN) (Henderson et al. 2002; Coe et al. 2008; Coe and Hess 2012, 2013; Coe 2012). The development and supply of products and services on a global scale can be fraught with difficulties due to the sheer geographical scale and diversity of operations, but, also in part to the interoperation of the many and varied organisations, their domains and the information systems they employ to facilitate their businesses. Additionally, many forces can influence GPN, many of which cannot be influenced or controlled by actors within those GPN (Damgaard and Spencer 2005), these can be political forces (e.g. relationships, trade agreements, war), environmental forces (e.g. weather and its potential adverse effects), legal forces (e.g. standards and safety legislation), social forces (e.g. social unrest and workforce strikes) and economic forces (e.g. exchange rates and financial uncertainty) (Levy 2008; Coe et al. 2008; Reuter et al. 2016). Hence, an ability to understand the risks involved for a given GPN, where they apply and how to best mitigate these by the design, redesign and reconfiguration of an organisation’s GPN could potentially be of great benefit.

The FLEXINET project aims to provide services that support the design and provision of flexible interoperable networks of production systems that can be rapidly and accurately re-configured based on the implementation of new technologies. It applies advanced solution techniques to the provision of a set of Intelligent Production Network Configuration Services that can support the design of high quality manufacturing networks, understanding the costs and risks involved in network re-configuration, and then mitigating the impact of system incompatibilities as networks change over time. FLEXINET takes the fundamental view that complex manufacturing systems which involve multiple partners with multiple technological capabilities require a semantically rigorous formal foundation upon which to base the flexible re-configuration of manufacturing information systems networks that can meet the needs of Small to Medium Enterprises (SME) as well as Original Equipment Manufacturers (OEM), i.e., a company which manufactures a complex product from components bought from another manufacturer (Oxford English Dictionary 2016). The three key FLEXINET industrial end user partners are especially interested in understanding the impact of external demands, such as environmental regulations, on their business and most especially when related to the introduction of new product-service opportunities into their production networks. These three industrial partners represent the domains of food and drink, white goods and industrial pumps. For them, the availability, accessibility and usability of reliable data as well as the ability to use it for strategic and tactical decisions is of particular importance.

The premise of this paper is to show the development of a reference ontology that can support ‘what-if’ GPN scenarios for a given set of constraints focusing upon the aspect of risk. The reference ontology has been built using both top-down and bottom-up approaches to enable the sharing of multi-contextual and multi-domain information and support the design and manufacture of PSS. The development of the reference ontology levels has utilised existing ontologies and international standards to aid their creation in a top down manner, whilst, a number of end user domain ontologies specially created for the project have helped inform and influence the structure and content of all the levels within the reference ontology. These have been created utilising: sets of end user requirements from the three industrial domains, a number of use cases created specifically for the project that represent those domains and three case studies, one for each of the end users. The reference ontology is detailed and presented within the paper, to which, its common-logic description is set out and explained. The application of this reference ontology is then illustrated with screenshots of the developed applications together with results obtained from testing and feedback. The main aim of the reference ontology is to support interoperability between information systems within multi-domain contexts for GPN configuration.

Fig. 1
figure 1

Ontology classification

Full size image

This paper is laid out in the following format. The literature review is put forward in “Literature review” section. The methodological point of view for the development of the research is set out in “Method” section. “The FLEXINET ontology and its development to support risk” section details the ontological approach that has been developed. “Results” section presents the results of the research and “Discussion” section contains a discussion about the pertinent issues involved. The paper is brought to a close with conclusions and further work contained in “Conclusions” section.

Literature review

The current corpus of scientific literature when considering the subject of interoperability, presents wide and varied attention to the research, development and application of ontologies to develop new approaches and technologies to problem domains. A large amount of this research reports upon ontologies that are built to support specific contexts with exact aims, each of these having been built wholly within their respective contexts from the ground up, thereby meaning they are domain specific and cannot profit from exposure to different viewpoints by being able to represent more than just one. The issue with this is that when considering interoperability and communication between different systems, contexts and domains, the seamless transfer of data, information and knowledge is unachievable, due to the fact that the very premise of understanding different viewpoints and domains and how they interrelate is the cornerstone to achieving interoperability (Borgo and Leitão 2004). This can be addressed by the development and application of a reference ontology (core ontology) so as to construct a common basis for the sharing of information and knowledge between multiple domains to therefore enable interoperability. Figure 1 presents a view upon the classification of the different types of ontologies. Foundation ontologies are high level ontologies (sometimes called upper ontologies or top-level ontologies) that comprise generic (domain independent) concepts, relationships and axioms that are able to represent and relate to any context dependent concept. As such, they are context independent and have very few constraining axioms. Examples of foundation ontologies are: the Standard Upper Ontology (SUO) (Neches et al. 1991), the Suggested Upper Merged Ontology (SUMO) (Niles and Pease 2001), Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE) (Gangemi et al. 2002) and Cyc-Ontology (Matuszek et al. 2006). Core ontologies are ontologies that have been specialised to some extent and are therefore broadly context dependent, but represent a number of different domains (Nardi et al. 2015). They are based upon and utilise concepts and relationships that exist within foundation ontologies. These ontologies still contain a minimal set of generalised concepts. These can be used as reference ontologies to be employed as building blocks to promote interoperability for much more domain specific and contextually dependant ontologies, yet enable communication between them due to the shared ‘common’ core concepts used to build them. Examples of core ontologies are: the Core Product Model (CPM) from the National Institution of Standards and Technology (NIST) (Foufou et al. 2005), the Manufacturing Core Ontology (MCO) (Chungoora and Young 2011a; Chungoora et al. 2012, 2013), the Manufacturing Core Concepts Ontology (MCCO) (Usman et al. 2011), the Manufacturing Information Systems (MIS) ontology (Hastilow 2013) and the UFO-S ontology (Nardi et al. 2015). Domain ontologies (Guarino 1998a, b) are ontologies that are wholly context dependant and are thus very specialised for their intended representation and purpose, these apply to specific activities.

Collaboration, enterprise and supply chain management ontologies

There are a number of widely available ontologies that centre upon collaboration, enterprise and supply chain management. Table 1 portrays an assessment of accepted and notable ontological approaches, it sets out the ontologies considered, their context, the level of formalisation, their key concepts and their approach. The aim of this is to illustrate both the commonalities and differences between the approaches.

Table 1 Assessment of ontologies relating to collaboration, enterprise and supply chain management
Full size table

Each of the ontologies represented in Table 1 seek to enable and enhance interoperability, be it for business, enterprise (virtual and distributed) or supply chain management. The enterprise and business ontologies are pertinent in that they represent aspects of organisations and can be applied to supply chain management and are therefore relative to context of the research within this paper. For interoperability to be successful, the semantic definition of concepts must be absolutely precise. For without this, discordancy in meaning can exist between concepts, thus hindering interoperability.

The TOronto Virtual Enterprise (TOVE) project (Gruninger and Fox 1996; Fox et al. 1996, 1997) sought to develop an enterprise ontology that could represent precise enterprise structures to then be used to model process integration within an enterprise. The purpose of this was to enable ontologies to be developed to answer queries within industrial environments to support the needs of organisations. It is comprised of a set of ontologies, those being: resource, organisational, product design, product requirements, manufacturing activity, manufacturing resource, order, transportation, quality, inventory and cost. The activity-state-time ontology can be considered to be an upper or top level ontology for the set of ontologies. The Enterprise Ontology (Uschold et al. 1998) was developed from the research conducted within the Enterprise Project. It consists of five main sections, which are: (i) activities and processes, (ii) organisation, (iii) strategy, (iv) marketing and (v) time. The premise of the ontology is to represent and model an enterprise utilising Ontolingua (Gruber 1993) and sets out a number of core concepts and relationships for just this purpose and is consistent with the TOVE ontologies. Madni et al. (1998, (2001) put forward the IST Distributed Enterprise Ontology (IDEON). This ontology was developed in an effort to unify the concepts and relationships of enterprise modelling and process/workflow management with respect to the domain of systems engineering. It has been developed so that it is compliant with the Process Specification Language (PSL) (ISO 18629). The IDEON ontology consists four of perspectives, these being (i) the Enterprise Context View, (ii) the Enterprise Organisation view, (iii) the Process view and (iv) the Resource/Product view.

Bjeladinovic and Marjanovic (2014) discuss the lexical commonalities and differences for TOVE (Gruninger and Fox 1996; Fox et al. 1996, 1997), EO (Uschold et al. 1998) and IDEON (Madni et al. 1998, 2001). They show there are differences in the way concepts are grouped. There are similarities too, an example of this is the concept for resource, it is shared between the three ontologies, albeit with slightly different naming conventions. This is an important concept relating to supply chains, resources are consumed to produce, manufacture and deliver products and services. Additionally time and location are present, they, again are useful for the representation of supply chains and the management thereof. The Virtual Enterprise Ontology (VEO) (Soares et al. 2000) is built upon EO, thus utilising many of its concepts and relationships. Whilst focused upon planning and control, examples of key concepts are organisation unit, resource, product and activity. However, Grubic and Fan (2010) state that EO has perhaps focused too much upon enterprise knowledge and not enterprise ontology, this observation is levelled at TOVE and parallels could be drawn against VEO too.

The Supply Chain Ontology (SCO) (Ye et al. 2008) sets out a number of generalist concepts and relationships that represent Supply Chain Management (SCM), examples being: supply chain, supply chain structure, performance, objective, activity and resource to highlight a few. SCO applies the Supply Chain Operations Reference model (SCOR) (Supply Chain Council 2014) to help describe the performance aspects. Zdravković et al. (2011) state that reference models ‘often lack semantic precision’, to which they present the SCOR-Full ontology. This was developed by firstly modelling the SCOR concepts and relationships to semantically define them in a more rigorous manner, from this the SCOR-Full domain ontology was developed to represent supply chain operational knowledge. It utilises the SCOR definitions so as to counter the ‘semantic inconsistencies of a SCOR reference model’. The main concepts are: agent, course, resource item, function, quality and setting, which, are mapped to the SCOR input/output elements. Sadly, the ontology does not define in detail supply chain activities. What can be gleaned from these two ontologies is that they both represent resource as an important concept. The SCO concept of resource relates closely to the TOVE, EO and VEO definitions, but the SCOR-Full terminology and representation is slightly different, where a resource item can be an information item or physical item. Additionally, in difference to the other ontologies, SCOR-Full models a course (i.e., an activity, process, method, procedure, strategy or plan) as having a setting (a description of the environment), which, can be considered a viewpoint or context.

Business-OWL (BOWL) (Ko et al. 2012) is an ontology that employs the Web Ontology Language (OWL) to represent collaborative business processes as a ‘hierarchical ontology of decomposable business tasks’ at a high level. The tasks represented by BOWL are those of: sales and marketing, inventory management, procurement and order management together with logistics and payment. Whilst not strictly representing supply chains, it exhibits many businesses activities that could be utilised within such a domain, those of business to business information systems. As the authors state, the tasks within BOWL can be decomposed and specialised by way of differing requirement sets, thereby representing different activities. Ko et al. (2012) cite the SCOR and MIT Process handbook (Malone et al. 2003) in relation to their work, but do not explicitly state whether or not they apply. Many of the BOWL concepts would need to be interpreted and specialised to map them to the aforementioned ontologies. A difficult concept to relate is task, this could be mapped to activity in TOVE, EO, VEO and SCO. EO states that activity means ‘something to be done’, but task within BOWL stems from the Hierarchical Task Network and breaks down into compound and primitive tasks, to which actions are called primitive tasks. Thus the semantics are somewhat difficult to align.

A Global Supply Chain (GSC) ontology is expounded by Wang et al. (2013) who seek to develop an ontology that goes beyond what is perceived as the traditional scope for a supply chain. Not only do they consider internal factors, but, external factors that an affect organisations and suppliers within a network on a global scale. It is comprised two ontologies: the core ontology consisting of five main classes, those being company, product, primary market, policy and financial status; the competitor ontology consisting of eleven main classes, which are corporation, financial status, supplier, customer, product, product type, price, price strategy, inventory and location. It must be noted, that whilst the ontology considers market environments, it does not consider wider factors that are part of GPN approaches, for example, those of the natural environment, political factors, social factors and technological factors. The GSC ontology does share some concepts with the other ontologies in Table 1. For example product can be mapped to IDEON and VEO, then to SCOR-Full and BOWL, although, for these, the names and classification structures are slightly different.

Geerts and O’Leary (2014) set out the Event, AGent, Location, Equipment, and Thing (EAGLET) ontology to represent a supply chain of things. The purpose of this is to enable interoperability throughout and along a supply chain relative to any one partner within it. Moreover, it supports multiple viewpoints for a standard set of economic phenomena relative to ‘an individual thing’s (object) identification information’. Those viewpoints are physical flow, chain of custody (i.e. who owns something at any point in time) and chain of ownership. As per the EAGLET ontology’s name sake, it is composed of five primitives, those of: event, agent, location, equipment, and thing, along with sets of relationships, modelled using Unified Modeling Language (UML) (Object Management Group 2012). It therefore needs to be more rigidly semantically defined for it to be used computationally to promote interoperability. Nonetheless, location is present within IDEON and agent is represented within SCOR-Full.

What can be derived from the ontologies represented within Table 1, is that there are many numerous concepts that exist for all of them. Some of these concepts are represented between a number of the ontologies, sometimes necessitating that concept names be interpreted, but, their semantic meaning is not always the same. When relating these ontologies to the context of risk and GPN, it can be said that none of them contain concepts to represent risk and it is only the GSC ontology (Wang et al. 2013) that represents market environments that relates to GPN. All of the ontologies do not represent GPN factors such as social, political, environmental or technological that can impinge upon and influence GPN.

Manufacturing reference ontologies

There are approaches that have been reported, showing efforts to devise tools, techniques and methods to address the issue of cross-domain interoperability. Borgo and Leitão (2007) set out a view upon the role of foundation ontologies and apply them to the domain of manufacturing control, showing that they can enhance and support interoperability between different applications. Panetto and Molina (2008) and Panetto et al. (2012) reinforce this view of the need to enable enterprise integration and interoperability within the wider the manufacturing enterprise to share information and knowledge between systems to support the development of technological solutions. Further aspects are put forward by Young et al. (2007), showing that heavy-weight logical approaches can be used to share manufacturing process information. Young et al. (2007), point towards the need to share such information and knowledge between different domains and show the value of linking both foundation ontologies and domain ontologies to enable a multi-domain sharing approach. Table 2 puts forward an assessment of current literature that focuses on the development of reference ontologies for various manufacturing contexts.

Table 2 Assessment of developed ontologies relating to manufacturing reference ontologies
Full size table

It has been acknowledged that undertaking research into the issue of sharing information and knowledge between different domains can be an arduous task. The crossing of boundaries between contexts and disciplines can encounter difficulties due to need to relate differing points of view and derive a common and accepted understanding, this often requires inordinate amounts of time and effort to accomplish this (Pisanelli et al. 2002). Nonetheless, there are other applicable research efforts that have focused upon interoperable heavyweight ontological approaches (Chungoora and Young 2011a, b; Chungoora et al. 2012, 2013; Imran 2013; Hastilow 2013), which seek to further the push towards formal, computable, semantic interoperability, specifically Common Logic based approaches (ISO/IEC 24707). Each of these approaches has applied an augmented version of Common Logic to the issue of interoperability to develop sets of concepts to form reference ontologies.

CPM is put forward by Foufou et al. (2005), developed by the NIST. It uses the now well accepted form, function and behavior views for the representation of product information to support the needs of product lifecycle management systems. Other concepts within the model are artifact, feature, flow, geometry, material, behavior, requirement and specification. CPM applies UML to represent the model and expressed in XML for computational purposes. As such, this too product centric to be of use relative to risk and GPN domains. Additionally, it is not semantically defined rigorously enough to be directly of use. Nonetheless, flow is an important concept in the reference ontology. The European Framework Programme 6 (FP6) Athena project produced a methodology called POP* (Process, Organisation, Product and others), which, is focused upon developing ways to capture design and management issues which occur during enterprise collaboration. Its motivation is to enable interoperability between collaborating enterprises using different modelling languages. A number of the concepts listed in Table 2 are important to the needs of the FLEXINET reference ontology, such as activity, location, gateway, event and state. POP* also has the concept flow represented within with maps directly the CPM flow concept. Both CPM and POP* do not represent concepts related to risk or GPN.

Annamalai et al. (2011) set out a PSS ontology. This seeks to represent the current servitisation efforts that ae happening in industry as orgainsations try to sell a combination of products and services to boost profitability and grow. The PPS ontology focuses upon top levels concepts. A number of these are of interest to the FLEXINET reference ontology, concepts such as supply network and infrastructure. Once again concepts relating to risk and GPN are not represented. The concepts of economic, environment and social are modelled, but the relate directly to the out of a PSS and have nothing to do with GPN.

The Interoperable Manufacturing Knowledge System (IMKS) project (Chungoora and Young 2011a, b; Chungoora et al. 2012, 2013) set out to formally model and define through-life engineering knowledge for manufacturing knowledge sharing across different domains. The project firstly developed lightweight UML models and then a heavyweight ontology that consisted of a design domain, a manufacturing domain and a set of core concepts which these two domain models related to. These were developed utilising the Common logic based Knowledge Frame Language (KFL) (Huber 2014). Mappings were built between the design and manufacturing ontology entities thus enabling cross domain knowledge sharing and hence support interoperability. One of the main outcomes of this was a set of generic manufacturing core concepts or reference ontology called the ‘Manufacturing Core Concepts Ontology’. In addition to this, two further approaches have taken the IMKS approach and built upon it. The first is that of Imran (2013) who focused upon the domain of assembly. This was been done by applying Common Logic-based ontologies and subsequently developing a set of key specialised reference concepts for the assembly domain utilising the IMKS work and the generic concepts within it. The aim of this was to support interoperability and thus enable the creation of specific application ontologies. The second approach is that of Hastilow (2013), who, again applied Common Logic-based ontologies for the domain of manufacturing information systems interoperability. The work from the IMKS approach was expanded to included product lifecycles and was specifically focused upon interoperation between defined systems. The Hastilow ontological work is currently being applied within the FLEXINET reference ontology.

A sustainable manufacturing ontology is presented by Borsato (2014). This focuses upon green manufacturing and the concepts that relate to Product Lifecycle Management (PLM), drawn from multiple standards, existing research work and various other sources. Concepts relating to environmental impact, environmental policy and environmental performance exist which ultimately relate to the concept of product. Hence environmental aspects are considered, but in the wrong context, i.e. not that of a GPN context, moreover risk is not represented.

The ontological approaches detailed in Table 2 have focused upon ameliorating the interchange of information and knowledge between multiple contexts and describe the organisation of relationships between concepts for products, manufacturing, assembly and design activities, PLM and sustainability. What is conclusive is that risk is only represent within one of the ontologies, the Manufacturing Intelligence Systems ontology (Hastilow 2013). Additionally, whilst some environmental and social concepts are represented, they do not relate to a GPN context. Nonetheless, the concepts needed to represent the factors that influence a GPN do not exist in enough quantity, or the correct context.

Risk ontologies

When considering the application of ontologies to the aspects of risk there are pertinent examples that exist as detailed in Table 3. Hofman (2011) proposes the application of ontologies to Linked Open Data for supply chain risk analysis. In this paper, the supply chain risk mostly refers to the risks that need to be monitored by governmental authorities (e.g. customs). The Linked Open Data is used to capture data from various sources in order to improve the efficiency of risk analysis needed for physical inspections. Emmenegger et al. (2012) introduce an enterprise ontology for the assessment of procurement risks in supply chains by considering both internal and external sources. The ontology was developed using the ArchiMate standard (The Open Group 2012) to model risk related concepts, such as Warning Signal, Risk Indicator and Risk Event. The approach has been implemented as an Early Warning System (EWS) for monitoring suppliers as part of the FP7 APPRIS project. In the same line of research, Emmenegger et al. (2013) have extended the risk assessment and monitoring approach by analysing the cases of the project’s three business partners. Both known risks as well as “black-swans”, i.e. risks that affect the company with no warning but have high impact, are considered.

As of the moment, there are few examples of ontologies supporting risk approaches particularly for the context of GPN.

Table 3 Assessment of developed ontologies relating to risk ontologies
Full size table

Overview of the literature review

Three main points can be deduced from the literature articles presented herein: (i) most of the ontologies do not address the aspects relative to GPN, i.e., aspects relating to political, social, technological, economic and environmental factors, (ii) the ontologies in sections “Collaboration, enterprise and supply chain management ontologies” and “Manufacturing reference ontologies” (except for Hastilow 2013) do not consider risk within the ontologies, and (iii) the majority of the ontologies have developed their ontologies utilising OWL due to its popularity and accessibility.

Against point (i) and point (ii) it is fundamentally important that all concepts of relevance to the problem domains are included in an ontology if the ontology is to be of real value. It is due to the complexity of meeting this challenge that FLEXINET is committed to pursuing a reference ontology for manufacture and that this paper contributes to this especially in relationship to risk concepts and risk analysis.

Against point (iii) it is clear that while useful progress is being made in the definition of formal ontologies using OWL that solutions based on this are limited to the expressiveness of Description Logic (Scheuermann and Leukel 2014). We take the view, given the complexity of the manufacturing area, that modelling methods that support higher levels of expressiveness should be consideration. To that end we follow the view expressed by Chungoora and Young (2011b), that Common Logic (ISO/IEC 24707 2007) based approaches, that are more aligned with full first order logic, should be exploited.

Overall, it can be seen from the literature assessed, that there are active ontological approaches being developed to address either interoperability or risk for a number of domains. But, there are few approaches focusing on the development of a reference ontology to enable interoperability for multi-contextual GPN that consider risk and support risk analysis.

Method

In line with development of a methodological approach for the research the context and phenomenon were studied to see if they would best fit a quantitative or qualitative viewpoint (Galliers 1991). Quantitative viewpoints focus upon the formulation of facts by way of numerical analysis of data, whereas, qualitative viewpoints focus upon understanding people and their actions within social and organisational settings (Easterby-Smith et al. 1991; Sarantakos 1993), additionally it is suited to the use of multiple methods to establish different views of phenomena. Thus, when considering the FLEXINET research project context and its scope, the best fit was a qualitative approach due to the fact the information and knowledge would be studied and that there would not be a lot of hard quantitative data to be gathered. To accompany this, a choice of philosophical perspective was necessary as this can affect assumptions about the collection of data and information. There are three paradigms or epistemologies that are generally applied to a research approach, those of positivist, interpretive and critical (Orlikowski and Baroudi 1991). Positivist research decrees that only what can be observed and measured is valid (Comte 1853), interpretive research tries to understand phenomena through the meanings that people assign to them (Boland 1985; Walsham 1993) and critical research seeks to determine and understand the status quo and thereby question theoretical and conceptual knowledge. It was deemed that the most appropriate would an interpretative perspective, as it was necessary to study and understand the three distinct industrial end users’ points of view. When analysing the various qualitative research methods that fitted a deductive approach, the methods of action research, subjective or argumentative research, futures research and role playing were rejected due to the constraints of the research project and the availability of the industrial end users. Hence, the research method of grounded theory (Glaser and Strauss 1967) was chosen. This enabled a deductive and iterative approach to be adopted to ground the theories in the data and information collected. Furthermore, it was thought that a single method alone might not account for all of the aspects that were being studied, so a mixed methods approach (Creswell 2008) was adopted. There are a number of well-founded methodologies that can be used for the development of an ontology, some of the more commonly accepted ones are those of TOVE (Uschold and Gruninger 1996), the Enterprise Model Approach (Uschold et al. 1998) and METHONTLOGY (Fernandez et al. 1997), together with the methodology of Noy and McGuiness (2001). Each of these has specific approaches for the study of data, information and knowledge to help the development of an ontology for any given domain or field of interest. The Noy and McGuiness (2001) methodology was chosen based upon the positive experience the authors have had in applying it to previous ontological research efforts and the outcomes that had been achieved. Furthermore, it possesses similar elements expounded by the other stated methodologies.

For the purposes of this paper, two main research questions were posited, in line with a deductive, qualitative approach, these were:

  1. (i)

    Can a heavyweight first order logic reference ontology structure be developed to define and represent risk knowledge for GPN?

  2. (ii)

    Can this ontological structure then be populated and queried to enable the assessment of risk scenarios to help configuration and reconfiguration of GPN for the development of product-services?

Ontology development

Three key industrial end users are involved with the research project, each within a different manufacturing sector. It has therefore been paramount that a fixed methodological approach be adopted, so that a standard and consistent approach to the elicitation, collection and analysis of data, information and knowledge could be applied, so as to minimise any variation that might occur between the three end users’ viewpoints, thus, providing an unbiased reference point.

The aim of the research project has been to develop a reference ontology for GPN. This has been brought into being by approaching it in two different directions as depicted within Fig. 2, which shows an adapted methodological approach that utilises the Noy and McGuiness (2001) methodology together with a grounded theory (Glaser and Strauss 1967) approach. Both the reference ontology and end user ontologies have utilised a standard set of steps to gather information and knowledge, then define the classes (or properties for first order logic), then define the relationships, the axioms and rules. A highly recursive and interactive approach enables questions to be asked through the development work and answered where possible to advance the research and development of the ontology. The development of the reference ontology applied a top down approach for developing the levels of the reference ontology, to which the original starting point was the novel research accomplished within the Interoperable Manufacturing Knowledge Systems (IMKS) (Chungoora et al. 2012) research project, the MI ontological model set out by Hastilow (2013) and the SCOR model (Supply Chain Council 2014). The Highfleet ULO (Highfleet 2014), which is based upon Ontoclean (Guarino and Weltey 2004), has been used as the foundation ontology on which the reference ontology has been built. This is due to the fact that the Highfleet Integrated Ontology Development Environment (IODE) application has been used to develop the reference ontology, due to its expressive common logic based approach. Furthermore, international standards have been studied and utilised where applicable, specifically, ISO 18629 1 (2004) PSL and ISO 19940 (2007) Enterprise Integration. These have provided an excellent basis for developing the higher generic levels of the reference ontology. The development of the end user ontologies has applied a bottom up approach, where data, information and knowledge has been elicited from the end user interviews, case studies, and specifically derived requirements to develop the three independent end user domain ontologies. These reflect the concepts, viewpoints and relationships of each specific domain. They have then been used to help create, form and populate the higher, more generic levels within the reference ontology. Hence, it has been a process of creating reference levels within the ontology that can represent the specific aspects within the end user ontologies at lower levels. Moreover, it has been important to make sure that those lower level ontologies map to the higher level aspects. This therefore formed a symbiotic relationship between the two approaches, where developments within one had to be represented within the other so that the ontological structures were consistent throughout.

Fig. 2
figure 2

Ontology development approach

Full size image

Case study design

For the purposes of the research a case study approach was judged to be the most appropriate. The widely accepted methodology is put forward by Yin (2009), who sets out the procedures necessary to undertake research in this manner. These are well defined and as such are a good fit for studying phenomenon within a contextually rich environment. Using these procedures three case studies were created to enable the capture of data for the testing of the posited research questions. A large proportion of time was spent collecting information from the three industrial end users necessary for the case studies. This consisted of a number of semi-structured interviews, accordingly product and procedural knowledge needed to be elicited, captured and formatted, hence, two methods were chosen, those of Cordingley (1989) and Bell and Hardiman (1989), these were applied to this end as they fitted the context within the end user organisations and was incorporated into the semi-structured interviews.

The grounded theory approach was applied throughout enabling an iterative approach, therefore, once data had been gathered it could be analysed and validated using the teach back method. The outputs from this could then be analysed again, or where insufficient data, information and knowledge had been collected or potential new aspects needed to be studied this was accounted for in the research approach. The final case study results were then presented by way of query search results output from the knowledge base.

The FLEXINET ontology and its development to support risk

An overview of the FLEXINET ontology

The knowledge classifications that follows from the full FLEXINET investigation is illustrated in Fig. 3, with each area being developed to suit the needs of a number of business and application areas. This is then exploited to as a reference ontology to support a range of knowledge fostering easier communication between different types of systems. The particular areas of importance to this paper are risk, production network, scenario, location, indicators and metrics, with concepts across these areas being shared with multiple other decision support applications.

Fig. 3
figure 3

The broad range of relevant knowledge domains

Full size image
Fig. 4
figure 4

Level 2 risk properties

Full size image

The main elements of the FLEXINET reference ontology are defined at five specific levels, as set out in Palmer et al. (2016), which provide progressive levels of specialisation from generic to more specific. The top level 0 is the most generic, with each level becoming more specialised and specific, until at level 5 it is focused upon specific End User domains. Level 0 is the upper level ontology (ULO) (Highfleet 2014) that has been adopted due the Integrated Ontology Development Environment (IODE) (Highfleet 2014) software being used to develop the heavyweight formal ontological approach. The focus at level 1 is systems and a whole, i.e. it represents anything that can be considered a system process or activity regardless of context or domain. At level two specialises the ontology by focusing upon designed systems (i.e. man-made systems), and natural systems. Level 3 again specialises the ontology by setting out systems that concern manufacturing systems. Level 4 sets out aspects that apply to the product lifecycle, whilst finally at Level 5 the focus is upon highly specialised End User enterprise specific ontologies. The scope of applicability for the FLEXINET reference ontology, at level 2, is mainly designed systems but does impinge upon natural systems. Whilst at level 4, the scope is that of design, produce and operate phases of a product lifecycle. More information upon the FLEXINET reference ontology and its levels are set out by Palmer et al. (2016).

One key aspect that the FLEXINET project has developed, is an ontology to support the development of GPN with the ability to assess risk for each of those networks utilising scenarios. This approach can enable companies to support cost comparisons and risk evaluations concerning the impact of introducing innovations in an existing GPN. Innovations could be at the level of product (e.g. new materials, new designs, new product lines), at the level of production process (e.g. new production technologies, new supply chains, new logistic concepts) or at the level of service (e.g. diagnosis, maintenance, energy saving, environmental sustainability). The goal is to support risk analysis by providing a store of answers and knowledge to provide answers for evaluations relative to a given set risk values.

The FLEXINET reference ontology that has been developed to support risk analysis is set out in the following manner. At level 2 there is a risk factors model that represents the concepts and relationships and constraints relative to the context of designed systems (see Fig. 4). At level 4 there are two models which relate to the context of product-service lifecycle systems (see Figs. 7, 8), those being (i) scenario and (ii) risk factors. These both set out once again the concepts and relationships and constraints necessary to represent what is necessary to model scenarios and risk for the reference ontology.

Level 2 risk factors

Level 2 ontology definition

Figure 4 illustrates the risk factors that exist at level 2 of the ontology. The Unified Modelling Language (UML) (Object Management Group 2012) technique has been applied to provide a visual representation and help describe the details about the concepts and relations necessary to specify risk at level 2. As can be seen in Fig. 4, Timespan is inherited from level 0, whilst Scenario is inherited from level 1. An Actor at level 2 is a role that is played by a System for a given Timespan, within a given Scenario within an Organization. An Organisation has a Location (again specified at level 2) and is related to Incident and Resilience. Incident is a specialisation of Event from the Highfleet Middle Level Ontology (MLO), whilst Resilience is defined as the ability of a GPN node to react to the disruptive event and its agility to compensate for the inoperability that has arisen. In turn Incident is related to Risk Factor, which, is encompassed by an internal factor (meaning ‘the inner strengths and weaknesses that an organisation exhibits’) or external factor (meaning ‘a general geopolitical, environmental or economic issue which can affect a GPN, but is outside its control’) that may influence a GPN adversely, accordingly, Organisation Specific Risk Factor, Regional Specific Risk Factor, and Location Specific Risk Factor are all specialisations of Risk Factor as per their namesakes. Additionally, Risk Factor is related to the concept Fuzzy Number defined as a special type of fuzzy set that represents a vague number.

This level 2 risk property UML diagram in Fig. 4, sets out the representation of risk for the FLEXINET reference ontology. It enables the creation of time dependent scenarios for an organisation that can contain different types of incidences and associated risk factors. Each instantiation of a risk factor can have fuzzy numbers associated with them, thus, enabling risk to be calculated and assessed for varying factors, incidences and hence what if scenarios to be created for analysis.

The FLEXINET ontology has been created utilising a common logic based language called the Knowledge Framework Language (KFL). This consists of properties (these being frames that allow concepts to be defined), relationships, axioms and rules. An example of a property at level 2 in KFL set out below. It shows RiskFactor, that it is an instance of a type (Inst Type), as such a type is something that always exists. It has a super-property (sup) of information at level 1 and MLO.Object at level 0. The rem statement is used to define the property in natural language, in this case the definition is ‘an internal or external factor that may influence a Global Production Network adversely’. The property of ‘Risk Factor’ is set out in KFL thus:

  • :Prop RiskFactor

  • :Inst Type

  • :sup Information

  • :sup MLO.Object

  • :rem “An internal or external factor that may influence a Global Production Network adversely.”

The associated relationship, that of ‘riskFactorHasActortype’ is set out below in KFL. It is an instance of a binary relationship between two properties with a rigid relationship (‘RigidRel’) i.e. these relationships will only hold over a particular timespan. ‘Sig’ states the properties of the arguments of the relationship i.e. in this case the relation must be between a ‘RiskFactor’ and an ‘ActorType’. ‘Args’ are strings that provide more detailed descriptions of argument properties. ‘Lex’ is a string template intended to provide a human-readable expression of its semantics. The KFL for the associated relationship of ‘riskFactorHasActortype’ follows here:

  • :Rel riskFactorHasActorType

  • :Inst BinaryRel

  • :Inst RigidRel

  • :Sig RiskFactor ActorType

  • :Args “RiskFactor” “ActorType”

  • :lex “?1 has ActorType ?2”

  • :rem “RiskFactor(s) have ActorType(s).”

  • :exampleRem “(riskFactorHasActorType FoodSafety 4PSPCtx.Producer)”

Axioms in KFL are constraints, which, allow the ontology to prevent inconsistent statements. There are two types of constraints within KFL, those being hard and soft, these are stated as IC Hard and IC Soft in KFL respectively, IC stands for Integrity Constraint. A hard constraint must be complied with and will therefore stop data being loaded, whereas, a soft constraint enables warnings to be generated when incorrect data is loaded, but, does not stop it being loaded. An example of an axiom at level 2 for risk is set out below in KFL. This axiom states that risk factor cannot depend on itself i.e., the first instance of a factor is not the same as the second instance of the factor.

figure a

Level 2 ontology implementation

To illustrate the implementation of the level 2 ontology, Figs. 5 and 6 depict the Risk Factor property as viewed within the Highfleet Integrated Ontology Development Environment (IODE) application, showing the relationships both in textual and graphical form. Figure 5 depicts the Risk Factor property within IODE, showing its relationships to other parts of the FLEXINET reference ontology, for example, Risk Factor: has an actor type, has a data source, has an incident, has a mitigation method and influences perturbation.

Fig. 5
figure 5

Level 2 risk factor relationships within the Highfleet IODE application

Full size image

Figure 6 sets out visually the inheritance and relationships for Risk Factor. It inherits from Information (1SYSCtx.Information) at Level 1 of the reference ontology, which in turn, inherits from Entity (1SYSCtx.Entity), that inherits from Basic (1SYSCtx.Basic), again both at Level 1. Additionally, Risk Factor inherits from Object (MLO.Object) which inherits from Concrete Entity (MLO.ConcreteEntity), both of these exist within the Highfleet Middle Level Ontology (MLO). The MLO is part of the Highfleet ULO, to which “the ULO distinguishes abstract and concrete entities on a spatial basis. Concrete entities are entities capable of being located as well as being locations. Abstract entities are entities that can neither be located nor be locations” (Highfleet 2014). Basic and Concrete Entity then inherit from Particular (RootCtx.Particular), which, in turn, inherits from Top ((RootCtx.Top), both of these reside within the ULO. Top is defined as ‘those things which exist are instances of Top, be it in an abstract, spatial, fictional, or other way’ (Highfleet 2014) and Particulars are ‘those things that are unique insofar as nothing else is the same thing as they are - particulars are only identical with themselves’ (Highfleet 2014).

Fig. 6
figure 6

Level 2 risk factor graphical view of relationships within the Highfleet IODE application

Full size image

Level 4 scenario

Figure 7 illustrates in UML format the specialisation of Scenario properties at level 4 of the FLEXINET reference ontology. At level 2 a project can be composed of the level 1 concept Scenario. At level 4 there are two subtypes of Scenario, those are GPN Scenario and Dependant Scenario. A GPN Scenario provides a view upon a GPN. A Dependent Scenario is contained within another Scenario and is dependent on the structure of a GPN scenario. In turn Risk Scenario and Business Scenario are subtypes of Dependent Scenario. Risk Scenario provides a view of risk factors upon a GPN system.

Fig. 7
figure 7

Level 4 scenario properties

Full size image

The Risk Scenario property as stated in KFL at level 4 is described in KFL below, it is an instance of a type (Inst Type). It has a super-property (sup) of DependentScenario and is defined as providing a view of risk factors upon a Global Production Network.

  • :Prop RiskScenario

  • :Inst Type

  • :sup DependentScenario

  • :rem “A RiskScenario provides a view of risk factors upon a \({<}\)sym>4PSPCtx.ProjectWorld</sym> system.”

Associated with this is the Risk Scenario relationship. It is an instance of a binary relationship, a rigid relationship and an antisymmetric binary relationship. The Sig states the properties of the arguments of the relationship, hence, the relationship is between ‘GPNScenario’ and ‘Scenario’. The Argument is between ‘component GPNScenario’ and ‘compound Scenario’. The ‘lex’ states that GPNScenario ?1 is contained within Scenario ?2. This enforces the relationship that only one given GPN scenario can be contained within scenario and that GPN scenario can be ‘IN’ a compound scenario. The Risk Scenario relationship ‘gpnScenarioInScenario’ is set out below:

  • :Rel gpnScenarioInScenario

  • :Inst BinaryRel

  • :Inst RigidRel

  • :supRel inScenario

  • :Inst AntisymmetricBR

  • :Sig GPNScenario Scenario

  • :Args “component GPNScenario” “compound Scenario”

  • :lex “GPNScenario ?1 is contained within Scenario ?2”

  • :rem “Only one GPNScenario can be contained within a Scenario. GPNScenario is IN compound Scenario. Given that GPNScenario and compound Scenario are not identical, then it is not the case that compound is IN GPN.”

  • (functionalArg gpnScenarioInScenario 1)

An example of an axiom at level 4 for Risk Scenario is portrayed in KFL below. The axiom states that a dependent scenario (?dpnS) is contained within a compound scenario (inScenario ?dpnS ?compound) and a GPNScenario is also contained within a compound scenario (inScenario ?gpnS ?compound), thereby developing the structure that ensures that only one dependent scenario (risk or business) and one GPN scenario may exist in a singular compound scenario and refer to each other. From this a dependent scenario can then be edited or adjusted so that it may represent a subset of the nodes that exist within the GPN scenario.

figure b

:IC hard “Given that a DependentScenario is in the same compound Scenario as the GPNScenario then a node in the DependentScenario must also be present in the GPNScenario. DependentScenario ?dpndS and GPNScenario ?gpnS are InScenario ?compound.

Level 4 risk factors

Level 4 ontology definition

Level 4 specialises risk (as shown in Fig. 8), by adding a number of concepts, both for Risk Scenario and GPN Scenario. A Risk Factor can influence a Perturbation which is the direct effect of disruption on a GPN node. For Risk Scenario (at level 4) Perturbation plays the role of an input. Related to GPN Scenario are Inoperability and Unit Loss of Inoperability that play the role of outputs. Inoperability is defined as the reduced percentage of operability of a GPN node as a result of the original disruption and propagation of that original disruption, compared with the expected level of operability. Accordingly, Unit Loss of Inoperability is defined as an average of inoperability over a time horizon, modelled as a MaterialRole so, a TimeHorizon can be applied to this property. For a GPN Scenario, Actor plays the roles of Actor. Related to actor is Actor Inter Dependency, which is defined as the interdependency coefficient that presents a probability of a disruption propagation from node j to node i. This concept has a relationship to Inter Dependency Rating, which is a specialised metric. Present within level 4 for risk are the concepts Criteria type and Linguistic Label. Criteria Type is the relationship between the network nodes. Linguistic Label is a metric that relates to levels of confidence, those being high, medium and low.

Fig. 8
figure 8

Level 4 risk properties

Full size image

The property for Inoperability at level 4 is an instance of a type (Inst Type) and has a super-property (sup) of Metric at level 2. It is defined in the rem statement as “the reduced percentage of operability of a Global production Network node as a result of the original disruption and propagation of a node”. The KFL for Inoperability is portrayed below:

  • :Prop Inoperability

  • :Inst Type

  • :sup Metric

  • :rem “The reduced percentage of operability of a Global Production Network node as a result of the original disruption and propagation of that original disruption, compared with the expected level of operability. A value of 0 % represents the normal operation of a node while a value of 100 % express the total and complete suspension of activities in a node.”

Aligned with the property of Inoperability, is the relationship ‘inoperabilityHasValue’. It is an instance of a binary relationship and a rigid relationship. ‘Sig’ states the properties of the arguments of the relationship between ‘Inoperability’ and ‘FuzzyNumber’. ‘Args’ state the relationships exists between the properties of ‘Inoperability’ and ‘InoperabilityValue’. The relationship is used to define that Inoperability has an InoperabilityValue and is set out below in KFL, furthermore, Figs. 9 and 10 illustrate the relationships of Inoperability within the IODE application.

  • :Rel inoperabilityHasValue

  • :Inst BinaryRel

  • :Inst RigidRel

  • :Sig Inoperability FuzzyMeasure

  • :Args “Inoperability” “Inoperability Value”

  • :lex “?1 has Inoperability Value ?2”

  • :rem “Inoperability has one Inoperability value.”

  • :exampleRem “(inoperabilityHasValue inop1 (fuzzyValTripleFN 0.1 0.2 0.3)) or (4PSPCtx.inoperabilityHasValue Inop1 (fuzzyValLinguisticCoupleFN 2DSCtx.Medium 2DSCtx.Medium)”

  • (functionalArg inoperabilityHasValue 2)

An axiom for ‘Inoperability as an output role’ states that in a RiskScenario (?riskS) an Inoperability (?inop) can only play an output role (Output ?role), as per the UML diagram in Fig. 8. It is listed in KFL below:

figure c

:IC hard “In a RiskScenario an Inoperability can only play an Output role. In RiskScenario ?riskS the Inoperability ?inop playsRole ?role which is not an Output.”

Level 4 ontology implementation

To demonstrate the implementation of the level 2 ontology, Fig. 9 shows the relationships for Inoperability within the IODE application, for example, Inoperability has time period and Inoperability has value. Furthermore, Fig. 10 portrays the inheritance for Inoperability within the IODE application. It shows it inherits from Metric (2DSCtx.Metric) at level 2 of the reference ontology. This then inherits from Information (1SYSCtx.Information) at Level 1, that inherits from Entity (1SYSCtx.Entity) and Basic (1SYSCtx.basic) at Level 1. Likewise, Metric inherits from Abstract Entity (MLO.AbstractEntity) from within the MLO. Basic and Abstract Entity then inherit from Particular (RootCtx.Particular) and Top (RootCtx.Top) from within the ULO.

Fig. 9
figure 9

Level 2 inoperability relationships within the Highfleet IODE application

Full size image
Fig. 10
figure 10

Level 2 risk factor relationships within the Highfleet IODE application

Full size image

Results

A collaborative decision support environment is being developed as part of the FLEXINET project, this enables GPN to be designed, configured and then evaluated from multiple perspectives. These cover a wide range of applications from managing new ideas, through product-service configuration and business modelling and onto global production network configuration and risk analysis. A start point for the risk analysis is to have a potential global production network on which to work. The facilities and their flows that are to comprise such a network are first visualised in a global environment as illustrated in Fig. 11, with each of the blue icons representing a supplier, production facility or customer, with the knowledge of the network held in a knowledge base built on the ontology. The risk application then explores specific risk scenarios based on the GPN scenario with added risk factors of interest.

Fig. 11
figure 11

A GPN scenario as the risk analysis start point

Full size image
Fig. 12
figure 12

The structure of a risk scenario

Full size image

An exemplar GPN scenario has been created representing the a drinks company. It is comprised of a producer that incorporates both a Cider Fermentation Plant and a Bottling Plant, the intended Customers and the suppliers involved in the GPN, those being: Suppliers of Apples, Suppliers of Yeast, Suppliers of Sugar, Suppliers of Flavourings and Suppliers of Sugar. This combined GPN scenario including risk scenario information is shown in Fig. 12. Here, the arrows, whilst clearly following the flows of materials, in fact represent the sensitivity of one node’s performance to disruption in another node’s performance, represented visually by the numbers at the end of the arrows. Also, the numbers shown in the top left corner of each node represents the level of risk for each node; the number in the bottom left corner of each node represents the inoperability impact of the risk on the node, but propagated through the network. Initially these numbers are set to zero but potentially range from zero up to one.

To help illustrate the knowledge base and show some of the instances that populate it, Fig. 13 shows a screenshot of the instances of the property ‘Scenario’ within IODE and Fig. 14 depicts a number of instances for the property ‘Inoperability’, again within IODE.

Fig. 13
figure 13

knowledge instatnces of scenario

Full size image
Fig. 14
figure 14

Knowledge instances of inoperability

Full size image
Fig. 15
figure 15

Risk scenario 1 GPN with calculated inoperability values

Full size image
Fig. 16
figure 16

Risk scenario 2 GPN with calculated inoperability values

Full size image

Two Risk Scenarios are set out for the GPN as illustrated in Figs. 15 and 16. Note that the boxes in the figure are coloured to add a visual reference to the levels of inoperability impact. Very low inoperability impact is coloured green as in Fig. 11, yellow represents a low inoperability impact, orange a medium level inoperability impact and red represents a high inoperability impact. Scenario one is a ‘Supply Failure’ in Suppliers of Sugar with an risk factor of 0.7 along with the supplier of apples having a low risk of 0.25 and supplier of yeast having a very low risk of 0.15. This scenario results in propagated inoperability impact in the cider fermentation plant of 0.41 as illustrated in Fig. 15. Scenario two is a ‘Supply Failure’ in Suppliers of Apples with a risk factor of 0.5 along with low risk factors of 0.15 and 0.25 for the supplier of yeast and the supplier of sugar respectively. In this case the propagated inoperability impact in the cider fermentation plant is 0.34 as illustrated in Fig. 16. From the knowledge base and ontology point of view what is important is that all these values can be stored and reused as required.

The knowledge environment, supported by the ontology, provides values into applications by the use of queries, an example of which is shown below. This query example states ‘for a given scenario, list the suppliers that exist and their inoperability values’. As shown, an organisation (?organisation) with inoperability (?inop) as an output role (?output_role) is queried for. Moreover, the organisation must be a member of a GPN (?GPNmember) and be a part of the scenario (?scenario). It is required that an organisation must have an output role, inoperability has a value (?inopValue) and that inoperability plays the role of an output for a scenario.

figure d

Applying this query to both Risk Scenario one and two, a set of inoperability values were calculated and are depicted in Table 4. This shows the resultant inoperability impact values as presented in the respective Figs. 14 and 15. Note in the table that the ontology has been created to support fuzzy numbers although the example has not used this facility. Therefore the inoperability values are listed as triples, but the same number three times.

Such an approach as illustrated, allows end users to add, edit and remove risks within risk scenarios (utilising the knowledge base) to then be able to assess the resultant calculated levels of inoperability between different scenarios, thereby bringing about the ability to understand and make better informed decisions when designing and formulating potentially beneficial and resilient GPNs.

Table 4 Query results for the risk scenarios
Full size table

Discussion

The research and results presented within this paper have been brought about by a lengthy and in-depth approach to the problem domain performed as part of the FLEXINET project. What can be deduced from this is that the research questions set out in the methodology have been answered successfully. A heavyweight approach utilising first order logic has been developed and successfully represents risk knowledge relating to GPN. Furthermore, these ontology information structures have been populated utilising end user industrial domain knowledge. These have then been queried to provide answers to risk related issues to then potentially help end users to design, configure and reconfigure GPN for PSS. Within this paper a simple risk scenario has been created to illustrate the approach and how it may be applied. By way of this, the ontological structures developed at levels 2 and 4 have been validated using this demonstration. What can be drawn from this is that the ontology is able to represent potentially diverse and relevant risk scenarios to aid the modelling and management of complex GPNs.

The results obtained thus far in the early stages of end user testing have provided good results. The FLEXINET reference ontology approach shown within the paper has multiple parts that relate to and influence a risk ontology. However, they also relate to other areas of PSS related to the strategic and tactical decisions concerning the configuration of production networks. Extensions to this that deal with operational decisions have not been addressed and are still needed as further work.

In approaching the development of a reference ontology to facilitate interoperability for PSS and GPN, few examples have been found in the field of manufacturing industry, nor business and enterprise. Moreover, when considering the application of ontologies to the domain of risk, examples do exist, but, do not address the domain of GPN, or the application of reference ontologies to risk within that domain.

The FLEXINET reference ontology and the risk ontology within it, have been developed utilising end user requirements, information and knowledge from three different and distinct industrial contexts. Furthermore, these developments have been influenced by current existing international standards that are applicable to the approach and related research material within the domain. Therefore, the developmental approach has forged together through an iterative manner, both top down and bottom up views to bring about the ontological approach described in this paper.

The industrial end users that are associated with the FLEXINET research project have expressed a real need to assess risk within a GPN and between different configurations of a given network. Thus, the approach developed within this paper puts forward a viable and new approach to the assessment of risk for multiple risk scenarios based upon a range of possible GPN scenarios.

Conclusions

The FLEXINET reference ontology that has been developed is focused upon supporting the decision making processes often found at the early stages of product development. Its main aim is to support interoperability between systems and domains, by way of the intelligent configuration of a network of products or PSS for GPN.

The research defines a reference ontology that can support risk assessment for GPN in an interoperable manner. This is due to the fact that risk scenarios are dependent scenarios that rely upon GPN scenarios, thereby providing an ontological link to other aspects of GPN design and configuration as depicted within Fig. 3, together with the concepts of facilities and location, which are necessary to be able to define risk factors for a GPN. These enable an interoperable risk application, in that it can interact with the other applications needed to configure and design GPN utilizing the ontology.

Level 2 of the reference ontology is detailed for risk, defining the more generic concepts that represent risk, production network, scenario, location, indicators and metrics.

Level 4 of the reference ontology is described, this defines the more specialised concepts and relationships for scenario and risk, showing how they relate to GPN scenario, facility, location, indicators and metrics.

Together, these contributions can provide a basis for organisations to build and develop interoperable information communication systems so as to enhance risk assessment approaches when considering ‘what if’ questions for different combinations of risk scenarios.

The development of the FLEXINET collaborative application suite, the supporting software services and reference ontology is still on-going. The breadth and depth of the reference ontology will continue to be enhanced and extended to meet the demands of new application functionalities. This will include extending the boundaries for it to be representative of the full range of economic and risk assessment. Hence, while this paper demonstrates the potential for such an approach there is an on-going requirement to expand the reference ontology.