quarta-feira, 5 de outubro de 2016

Manufacturing reference ontologies – a route to knowledge sharing and interoperability? - Bob Young - Keynote@Ontobras 2017



Manufacturing reference ontologies – a route to knowledge sharing and interoperability?
Bob Young - Loughborough University, UK

The main idea is to use ontologies to support Decision Making in Manufacturing. 

He points out the need for Manufacturing Reference Ontology

Manufacturing Ecosystem Activities (interesting slide!):

  • Strategic Management Activities
  • Product Design Tactical Planning Activities
  • Operations Management Activities
  • Shop Floor Activities 
Multiple software system support manufacturing decisions. It is very hard to interoperate them, usually this is very expensive and error prone.

Definitions he uses:
  • Foundational Ontology - context independent
  • Reference Ontology - broad context dependency
  • Domain Ontology - detailed context dependency
The IMKS Concept - very interesting diagram. He says: "this is the diagram that got us the money to do it"
The slide includes the manufacturing life cycle (activities presented above), then this life cycle is supported by World Models (libraries of semantically defined things, processes, relationships... This is supposed to provide interoperability, collaboration and terminology. And ultimately help decision making.

The IMKS approach does not ensure interoperability. Instead, it provides understanding of interoperability potential, allowing informed choices to be made.

He presents a very interesting example of viewpoint variation, i.e. one particular device being seen differently in the perspective of the designer and the manufacturer.

Linking production knowledge back to product design
There are different documents, sometimes in natural language, or structured in tables, or even using conceptual models, representing the Design view and the Production view. You must be able to extract and relate the knowledge from all of them.

Similar work has been done for assembly:
key reference concepts in design for assembly and assembly planning (Imram 2013). Equivalent extensions also needed for other manufacturing processes, e.g. forging, casting, etc. This is still a need. But, most importantly, the relationship between them must be found!

Every time a company changes a software system, things don't actually fit as they used to. And usually, you may spend from 12 to 18 months just  to make things fit again. Thus, there is an opportunity here for using ontologies to support a smoother transition to normality.

For that, you can apply a simple system to system requirements evaluation, in which for the output of one system to be useful it needs to match the need of the input of the other system.

This project involves: Collaboration Environments (CE), Business Model Development (BMD), Network Configurations (NC) and Risk Assessment (RA). The project concerns these topics with focus on Knowledge Sharing. 
The ontology environment was supposed to underly all the others (CE, BMD, NC and RA), providing the knowledge to interoperate them.

In Flexinet, a reference ontology supports KB construction and interoperation across software services (interesting diagram on slide)

The ontology was built in layers, going from foundational to enterprise specific ontologies. 
Level 0 - CORE (ULO) - foundational ontology
Level 1 - Systems (functions) - PLS-ISO 18629
Level 2 - Designed Systems
Level 3 (context) - Manufacturing Business System
Level 4 - Product-Service Lifecycle systems. Scope: Produce
Level 5 - Enterprise Specific
He says: "The bit that helps enterprises to interoperate must be common (thus, it should be standard!!!)."

There are several modules in the reference ontology, for the different aspects of Flexinet. 

Evaluation of the use of the Flexinet reference ontology: The reference ontology has ben used to build 4 end user knowledge bases; 74 queries have been developed to support the flexinet software services shown cross-domain knowledge sharing potential; etc.

Future works:
- extend the work for operational decision making (as it is now on strategic and tactical levels)
- extend the scope for in-factory operations (inlcuding links to cyber-physical systems
- extend the idea for other domains (outside manufacturing)

Two fundamental questions: 
1) the use of specialization levels (layers) seems to work, but do we have the right levels?
2) how do we make one ontology instead of ontology chucks (modules)?

Nenhum comentário:

Postar um comentário