reference ontologies for manufacturing bob young - [email protected] r young, n hastilow, m...

24
Reference ontologies for manufacturing Bob Young - [email protected] R Young, N Hastilow, M Imran, N Chungoora Z Usman and A-F Cutting-Decelle

Upload: sandy-hoar

Post on 14-Dec-2015

213 views

Category:

Documents


0 download

TRANSCRIPT

Reference ontologies for manufacturing

Bob Young - [email protected]

R Young, N Hastilow, M Imran, N Chungoora Z Usman and A-F Cutting-Decelle

Outline

• Background - lots of useful standards • Need for multiple standards across

manufacturing• Problems in interoperability across standards • The IMKS project and the use of formal

semantics • Towards a reference ontology for manufacture

GlobalManufacture

Key areas:

• Modelling Manufacturing Capability • Product Lifecycle Management

• Knowledge Sharing and Reuse

• Integration and Inter-operability

Design for Manufacture

Concurrent Engineering

Manufacturing Planning

Supply Chain Capability

Information& Knowledge

Infrastructures for

Manufacture

ICT in Manufacturing – background to our work at Loughborough University

Manufacturing Industries:

• Aerospace

• Automotive

• Machine tools

• Electrical machines

• Injection moulding

• Food

Lots of useful standards

• Focus mainly on ISO TC 184 SC4 – “Industrial data”• Examples of useful standards

– ISO 10303-1 STEP overview– ISO 10303-224 machining features– ISO 10303-239 Product Lifecycle Support– ISO 13584 Parts Library– ISO 15531 MANDATE– ISO 18629 PSL– ………………..

STEP-ISO 10303

ISO 13584PLIB

ISO 18629-PSL

STEP NC ISO 10303

ISO10303-AP239-

PLCS

ISO 15531MANDATE

STEP-ISO 10303-AP224 Feature Based Manufacturing

ISO13399-Cutting Tool

Standard

Issues in using multiple ISO Standards for information sharing

• Multiple Interpretations of nominally the same concept

• Multiple definitions of the same term

Example: multiple interpretations

from PRODUCT DEFINITION (ISO 10303-41) (uses definition from ISO 10303-1)

”a thing or substance produced by a natural or artificial process”e.g.: Product definition from (ISO 10303_1)

ENTITY Product ABSTRACT SUPERTYPE OF (ONEOF (Breakdown, Breakdown_element, Document, Interface_connector, Interface_specification, Part, Requirement, Slot)); id : STRING; name : STRING; description : OPTIONAL STRING;END_ENTITY;

from PLCS Part-439 (ISO 10303-439) (uses definition from ISO 10303-1)

Multiple definitions for the same term

from MACHINING FEATURE (ISO 10303_224)

“A Part is a material or functional element that is intended to constitute a component of different products”

from PLIB (ISO 13584_1) “A Part is the physical item which is intended to be produced through the manufacturing process. Each Part may be one of the following: Manufactured_assembly, or Single_piece_part.

The data associated with a Part are the following:

— manufacture_authorization;— manufactured_by_organization;— manufactured_by_person;— owned_by_organization;— owned_by_person;— part_description;— part_id;

— part_name; — part_revision_id; — physical_form; — property_characteristics; — quantity_ordered; — security_classification.”

Example: Part

• Resource (ISO 15531-1; ISO 18629-1): Any device, tool and means, except raw material and final product components, at the disposal of the enterprise to produce goods or services. This definition includes ISO 10303-49 definition.

• Resource (ISO 10303-49): Something that may be described in terms of a behavior, a capability, or a performance measure that is pertinent to the process.

• Resource (ISO 15704): An enterprise entity that provides some or all of the capabilities required by the execution of an enterprise activity and/or business process.

Michel, J.J., 2005. Terminology extracted from some manufacturing and modelling related standards. CEN/TC 310 N1119R2.

Problem – multiple standards with multiple semantics

ISO TC184/SC4 Future architecture Rotterdam 2009-11-13

SC4 recognise need for formal ontologies

Industrial

Data

Integrated

Ontologies and

Models

ISO TC184/SC4 Future architecture Rotterdam 2009-11-13

definitions of the concepts

definitions of the concepts

data modelschemas

data modelschemas

information flows

information flows

processcomponents

processcomponents

processcomponents

ARM schemasanalyse scope

information flows

AIM/MIMschemas

analysis informationrequirements

defines the data about the concepts needed to

fulfil the information requirements

data modelschemas

data modelschemas

implementationspecification

domain knowledgedomain knowledge in AAM

mapping

domain knowledge as reference data

reference datareference datareference data

Current ISO 10303 approach

ISO TC184/SC4 Future architecture Rotterdam 2009-11-13

reference data

knowledge of the concepts

knowledge of the concepts

reference data

definitions of the concepts

definitions of the concepts

data modelschemas

data modelschemas

information flows

information flows

processcomponents

processcomponents

processcomponents

definitions of the concepts

analyse scope

information flows

data modelschemas

analysis informationrequirements

defines the data about the concepts needed to

fulfil the information requirements

reference data

data modelschemas

data modelschemas

implementationspecification

domain knowledgedomain knowledge

knowledge of the concepts

(an ontology)

A part of the IDIOM approach

Common Concepts

KnowledgeVerification

Formally defined core-concepts i.e. using logic statements

Specialised domain Concepts

Specialiseddomain

concepts

CommonKB

Specialised KB

Specialised KB

Concept underlying a Manufacturing Reference Ontology (from IMKS)

Formal definitions using a Common Logic base - KFL

(=> (Core.Resource ?r) (exists (?c) (and (Core.Capability ?c) (Core.hasCapability ?r ?c)))):IC soft "Every resource may have some capability." (=> (Core.Resource ?r) (exists (?e) (and (Core.Enterprise ?e) (Core.isHeldBy ?r ?e)))):IC soft "Every resource may be held by some enterprise." (=> (Core.Resource ?r) (exists (?p) (and (Core.Process ?p) (Core.isUsedBy ?r ?p)))):IC soft "Every resource may be used by some process."

•Cannot be misinterpreted

•Can be used to build new ‘specialisations’ to suit specific requirements

•Inferences can be made based on the logic

Foundation

Ontology SpecialisationTime

System 6

Version 8

The level of compliance of new systems or new system versions can be checked

Reference ontology aspects explored to date

• Design for machining• Design for assembly• Interoperability compliance across

manufacturing systems

The IMKS project developed a proof of concept formal ontology related to sharing knowledge across product design and machining

The concept extended across design for assembly and assembly planning

The concept extended to manufacturing systems interoperability

Formalisms specified in KFL and exploited in HIGHFLEET’s XKS environment

Each of the sets of concepts illustrated in these figures have been formally specified in KFL

They have been implemented and used in knowledge sharing and interoperability validation experiments.

• (=> (Feature ?f)• (exists(?AOI)• (and

(AttributeOfInterest ?AOI)• (hasAttributeOfInterest ?f ?

AOI))))• :IC hard "Every feature has an

Attribute of Interest•  • (=> (FormFeature ?ffeature)• (exists (?form)• (and (Form ?form) • (FormFeature ?

ffeature)• (hasAttributeOfInterest ?ffeature ?

form))))• :IC hard "A Form exist as an

Attribute of Interest for a FormFeature”

•  

(=> (DesignFeature ?df) ((exists(?function) (and (Function ?function)

(hasAttributeOfInterest ?df ?function))))):IC hard "A function exists for a DesignFeature" (=> (ProductionFeature ?Turningf) (exists (?mfgmethod)(and (ManufacturingMethod ?manufacturingmethod) (hasAttributeOfInterest ?Turningf ?mfgmethod)))):IC hard "ManufacturingMethod exists for every Productionfeature"

An Example - Feature Specialisations in Common

Logic

The FLEXINET Concept – a new FP7 FoF project in negotiation

Conclusions• The approach is showing significant potential

• There is much still to be done

• The approach we have taken is pragmatic– There will be a need at some point for an agreed set of

underlying foundation concepts– As formal semantic languages develop there will be a need for

them to remain compatible

• There will be a balance to be found between the benefits of enabling interoperability and the costs and constraints of designing formally constrained semantic systems