Enterprise Modelling:
Objectives, constructs & ontologies
F.B. Vernadat
LGIPM, University of Metz, France
Eurostat, European Commission
Tutorial held at the EMOI-CAiSE Workshop
Riga, Latvia, June 7, 2004
F.B. Vernadat 1
Short Bibligraphy
ESPRIT Consortium AMICE, CIMOSA: Open System Architecture
for CIM, 2nd edition, Springer-Verlag, 1993.
Petrie, C. (ed.) Enterprise Modeling Technology, The MIT Press,
1992.
Vernadat, F.B. Enterprise Modeling and Integration: Principles
and Applications, Chapman & Hall, 1996.
Bernus, P., Mertins, K., Schmidt, G. (eds.) Handbook of
Information Architectures, Springer-Verlag, 1998.
Kosanke, K. and Nell, J. (eds.) Enterprise Engineering and
Integration: Building International Consensus, Springer-
Verlag, 1997.
Molina, A., Kusiak, A, Sanchez, J. (eds.) Handbook of Life Cycle
Engineering, Kluwer Academic Pub., 1998.
Kosanke, K. et al. (eds.) Enterprise Inter- and Intra-Organizational
Integration: Building International Consensus, Kluwer
Academic Pub., 2003.
F.B. Vernadat 2
Contents
Enterprise Modelling
Why?
What?
How?
Modelling Constructs
Function View
Information View
Resource View
Organisation View
Enterprise Ontologies
CIMOSA Ontology
TOVE Ontology / PSL
Enterprise Ontology
F.B. Vernadat 3
Part I
Enterprise Modelling Objectives
F.B. Vernadat 4
Enterprise Modelling: Why?
Rationale: The highly competitive global
economy forces companies to:
Fully understand and harness the way they operate
Align their organisation structure with changing business needs
Integrate enterprise networks (Extended Enterprises,
Virtual/Agile Enterprises, Supply Chains, ...)
Implement large interoperable information systems (e.g. MES,
ERP, PDM, SCM, ...)
Continuously optimise their operations, facilities and
management in terms of Quality, Costs & Delays (QCD)
F.B. Vernadat 5
Enterprise Modelling: Why?
Modeling Framework
Organisation/ Human
Enterprise
Model
Economic aspects aspects
(Semantic Unification)
concepts concepts
Physical
Flow
System A System B
(Information Flow)
Information Flow
Technical Co-ordination
Integrating
aspects aspects
Infrastructure (IIS)
F.B. Vernadat 6
Enterprise Modelling: Why?
Major drivers for EM applications:
Diagnosis of a disorder (material, information or control flows)
Restructuring a business entity (to improve its performances)
Business Process Reengineering (BPR)
Large scale systems integration / interoperability
Implementation of MES, ERP, PDM or APS systems
Tuning the organisation structure to face business change
Alignment or conformity to norms (ISO 9000, ISO 14000)
Management decision (activity externalisation/internalisation)
F.B. Vernadat 7
Enterprise Modelling: What?
Definition: Enterprise Modelling (EM):
- The art of externalising knowledge which adds value to the
enterprise or needs to be shared, i.e. to describe the things of
the enterprise
- Concerns function, behaviour, information, resource,
organisation, economic or other aspects of a business entity
- Used to represent the structure, behaviour, components and
operations of a business entity to understand, (re)engineer,
evaluate, optimise and even control business operations and
performance
Must be open to simulation/analysis and decision support
F.B. Vernadat 8
Enterprise Modelling: What?
Enterprise model: not one monolithic model but an assemblage of models
Functional Model Organisation Model
ABC Enterprise
Information Model Resource Model
F.B. Vernadat Economic Model 9
Enterprise Modelling: What?
Added value of EM:
The four essential goals of Modelling, i.e.:
- to understand/explain
- to experiment (analyse, compare, test, evaluate/predict
performances)
- to learn & decide (what-if scenarios)
- to operate/control
govern developments in Enterprise Modelling
Major advantage: to build a common consensus on how
enterprise operations work (or should work)
F.B. Vernadat 10
Enterprise Modelling: What?
Brief EM history & background:
Mid-70's: SADT, ER model, DFD, semantic nets (IT appli. dev't)
80's: CIM methods (ICAM-IDEF, GRAI, CAM-I)
Late 80's: EU AMICE's CIMOSA / BPR (process orientation)
Over the 90's:
- ERP deployment (DEM, ARIS, ...)
- Workflow management systems (WPDL)
- Object orientation (IEM, UML, ...)
- Ontologies (IDEF5, TOVE, Enterprise Ontology, PSL, i*)
F.B. Vernadat 11
Enterprise Engineering: Ref. Archi.
Generic
Views Subdivision
Partial
GERAM } according
{ { { Particular to genericity
(IFAC/IFIP Task Force)
Instantiation
Identification Customer service Subdivision
according to purpose
Concept }
Management of activity
and control
Requirements Software } Subdivision
Hardware according to physical
Preliminary design manifestation
Design Resource
Detailed design Organisation } Subdivision
according to
Implementation Information
Function model content
Operation
Decommission Machine } Subdivision according
to means of
Human
Life-cycle implementation
phases
F.B. Vernadat 12
Reference Architecture Particular Architecture
Enterprise Modelling: How?
Design/Reengineering Phase
Conceptual Model Conceptual Model
AS-IS Transformation TO-BE
of existing system of future system
Conceptual Level
Existing
System Reengineered
System
Real-world
Analysis Phase Implementation Phase
Rule: Must rely on a participative approach
F.B. Vernadat 13
Enterprise Modelling: How?
EM Good News:
Many commercial EM tools:
ARIS Toolset, FirstSTEP, Bonapart, KBSI tools, PrimeObject,
Enterprise Modeler, MO2GO, emaGIM, CimTool, ...
Many Workflow Management tools:
IBM Flow Mark, Oracle Workflow, Ultimus, WorkParty,
Ensemble, InConcert, Action Workflow, OPEN/Workflow,
Staffware, Lotus Notes, ...
F.B. Vernadat 14
EM bad news:
Tower of Babel situation
F.B. Vernadat 15
EM: Panorama of tools
ARIS ToolSet (IDS Scheer)
Metis (NCR)
FirstSTEP (Interfacing Technologies)
MooGo/IEM (IPK Berlin)
CimTool (RGCP)
GraiTools 1.0 (GraiSoft)
F.B. Vernadat 16
ARIS ToolSet
IDS Scheer, Germany (1993)
Number 1 in sales worldwide
Four integrated modelling views
Event Process Chain (EPC model)
Business process analysis orientation
Software engineering orientation
Limited simulation capabilities
Runs on Windows, Unix, Linux PCs or servers
F.B. Vernadat 17
ARIS Architecture
Organisation
enterprise
plant
area
planning levels organisationnal chart
AND
Entity F2 F4
Relationship F1 F6
Model (ERM) F3 F5
Process
F
AND F1 F2
F3 F4
Hierarchy
Data Control Function
F.B. Vernadat 18
ARIS ToolSet
F.B. Vernadat 19
ARIS ToolSet
The state of the process
change to RVAL
$status$
process_state The RSPOB will inform all the persons who are impacted by
this modification that this is effective in the bill of material
legacy system.
$DEP_OCM$ Diffusion to
DEP_OCM RSPOB
clients
OPAL
DEP/OCM
Email Diffusion
desktop 4 cancelled
achieved
$DEP_OCM$,$status$
$status$ After the impact of the modification
The status of the process process_state in the PSA legacy system if the DEP_OCM
change automatically to CLOS is validated or after the rejection of
the DEP_OCM if it is cancelled, the status
Close of this object is CLOS
DEP_OCM
session
$DEP_OCM$
DEP_OCM
END_OCM
F.B. Vernadat 20
Metis
Developed by NCR Inc. and Computas (Norway)
Enterprise knowledge acquisition & vizualisation tool
Used for Enterprise Architecture definition
Good for organization analysis and design
Runs on Windows
F.B. Vernadat 21
Metis
F.B. Vernadat 22
Metis
F.B. Vernadat 23
FirstSTEP
Interfacing Technologies (Montreal, CDN)
Kernel developed by NRC Canada, Ottawa
Modelling and decision-support tool
Well-suited for "What-if" scenarios by managers
Embedded simulation capabilities
(espec. costs and resource capacities)
Runs on Windows PCs
F.B. Vernadat 24
FirstSTEP
F.B. Vernadat 25
FirstSTEP
F.B. Vernadat 26
MooGo/IEM
Commercialised by PSI, Germany
Developed by IPK Berlin (1994)
Based on SADT model
Strong object orientation
Three fundamental types of objects:
Order, Product, Resource
F.B. Vernadat 27
MooGo/IEM
a) descriptive Features b) modeled Objects
controls the execution
of resources Order
Product
products, orders or Object processed
Action Object Order
resources to be state a state b - orders,
processed - products
Actions transfer objects - resources
of state a into state Resource
executes the action
b,
controled by orders
and under the use Resource - physical Ressource
- Information-Resource
of
resources
c) connecting Elements
sequence case distinction uniting loop
parallel
Quelle: IPK / MOGO
F.B. Vernadat 28
,
MooGo/IEM
Customer Generate
CO Order
O Factory
Processing Order
COP Operator1 COP Operator1
R R R R
CR O
Generate Validate
Manufacturing Manufacturing
Orders Plan
MRP Operator2 MRP Operator2
R R R R
Raw Gear-Boxes
Shop
Materials P P
Floor
Purchased Operations Gears P
Items P
SFS Foreman
R R
F.B. Vernadat 29
CimTool
Developed by Renaches Consultants (1995)
Based on CIMOSA constructs
Limited to modelling
(function and information views mostly)
Very easy to learn and to use
Runs on Windows PCs only
F.B. Vernadat 30
F.B. Vernadat 31
CimTool
Start
CdCTechniqueOrgane
CdCDone
DmpositionEnPis
LancerEtude
EtudePi
ResteAfaire
EtudesPiecesFaites @PiSuivante
Montage/AssemblageOrgane
MontageOk
ValidationOrgane
ValidationOk
DossierTechniqueOrgane
DossierTerminr />
Finish
F.B. Vernadat 32
GraiTools 1.0
Developed by GraiSoft, Bordeaux (2003)
Specificity: based on the GRAI method
Strength: decision centre analysis
Complete environment for BPM, enterprise modelling
and project monitoring
Perofrmance indicator deployment
Runs on PCs
F.B. Vernadat 33
GraiTools 1.0
GRAI grid
Decision centres
Business processes
F.B. Vernadat 34
Characteristics of Enterprise
Models
Scope Coverage
Coverage
Level of details
Competency Scope
Completeness
Consistency Project
Time & Cost
Level of details
F.B. Vernadat 35
Part II
Enterprise Modelling Constructs
F.B. Vernadat 36
Enterprise Modelling Constructs
Definition:
A construct is a primitive component (with syntax and
semantics) of a modelling language
It is subject to rules for combining/putting together
constructs to build models of any size
Appearances:
Graphical notation (e.g. SADT/IDEF0, IDEF3, ER models)
Template / object class notation (e.g. CIMOSA, IEM)
Formal notation (e.g. TOVE, UEML)
F.B. Vernadat 37
ARIS Toolset Language
Event-Process Chains (EPC)
Event
Function
Information Object
Entity
Relationship
Organisation Unit
Employee
IT-Resource
F.B. Vernadat 38
CIMOSA Language
CIMOSA
Event-driven process-based language
- Process/Operation/Agent relationship
- Task/Capability-Competency/Agent relationship
Event Ev = (Eid, source, P-list, Predicate, Date)
Process P = (Pid, ? P, ?P, ?P, ES)
?P = {WHEN (condition) DO action}
Activity A = (Aid, FI, CI, RI, FO, CO, RO, CS, ? A, ES)
CS= set of capabilities/competencies
Resource R = (Rid, CS, FO-list, components)
Object View OV = (Ovid, O-list, Properties)
Enterprise Object EO = (Oid, Isa, Part-of, Properties)
Organisation unit
UO = (UOid, tasks, responsibilities, authorities)
Organisation cell
EO = (Eoid, manager, responsibilities, authorities, components)
F.B. Vernadat 39
ODP Metamodel
Process 1..1 achieves
Community
CoreCommunity 0..*
1..*
0..* Step CoreRole 1..*
CoreCommunity 1..1
0..* participates
Role
sequence 1..* RoleFiller
0..* Task 0..* SuperWho
0..* 0..*
0..* 1..1 1..1 1..1
fills
0..* Objective
referenced by
partial order participates Object
0..* Action 0..* 1..* 0..*
0..* 0..* steers toward
0..* 0..* represents
referenced by CEO
partial order
0..1 0..*
1..1
Behaviour Policy
F.B. Vernadat 0..* influences 0..* 40
CEN EN 12204
ENTERPRISE between RELATION
OBJECT state of OBJECT
view of STATE type of
can play the role of used in
OBJECT BUSINESS SEQUENCING
VIEW PROCESS RELATIONSHIP
involved in employs
ORDER
RESOURCE combined by
PRODUCT
ENTERPRISE used in
provides ACTIVITY
ORGANISATION
UNIT
CAPABILITY required by EVENT
SET
Comiturop de Normalisation, Bruxelles
F.B. Vernadat 41
Enterprise Modelling paradigm
Three essential concepts: process, agent and operation
A process is a partially ordered sequence of steps to achieve a
goal (or end-result)
Processes = What has to be done
Operations = Primitive actions (required or provided)
Agents = The Doers (those who carry out the processes)
Three companion concepts: event, activity and object view
Events = Process triggers (happenings requiring actions)
Activities = Process steps
Object views = Processed items (objects involved in processes)
F.B. Vernadat 42
Enterprise Modelling paradigm
Three types of processes:
Well-structured processes (behaviour is deterministic)
Semi-structured processes (behaviour is partially known)
Ill-structured processes (behaviour is not predictable)
Three types of agents:
Machines (devices with a controller)
Applications (IT systems)
Humans
F.B. Vernadat 43
Enterprise Modelling paradigm
Principle of separation of processes and resources
Chains of What has
Processes
Activities to be done
Fonctional Capabilities/
operations Competencies
Resources
Operations & The doers
(agents)
States
Machines Applications Humans
F.B. Vernadat 44
EM Constructs: Information View
Enterprise Object: Any entity (physical object or
information) in the enterprise subject to be referenced
in enterprise activities or in the organisation structure
Ex.: orders, products, resources, invoices, process plans...
Formalisation:
EO = ?EOid, Isa , Partof , Prop ?
EO EO EO
EOid enterprise object name, Isa generalisation/specialisation
EO
relationship of EO, Partof aggregation relationship of EO,
EO
Prop list of properties (or attributes) of EO. Isa and Partof
EO EO EO
define semantic relationships of EO with other enterprise objects
F.B. Vernadat 45
EM Constructs: Information View
Object View: Is a manifestation (state and
embodiement) of one or more enterprise objects
Ex.: Let Purchase_Order (PO) be an enterprise object, then
Blank_PO, Filled_In_PO, Signed_PO are object views on PO
Formalisation:
OV = ?OVid, EO , Prop ?
OV OV
OVid object view name, EO list of enterprise objects from which
OV
the object view is derived, Prop list of properties of the object
OV
view (derived from list of properties of objects in EO )
OV
F.B. Vernadat 46
EM Constructs: Function View
Event: represents a change of state in the system
Solicited event: scheduled order, clock-time = 5:00 pm, etc.
Unsolicited event: machine break-down, alarm, error
message
Formalisation:
E = ?Eid, q, OV, t?
Eid agent name, q predicate (state change condition), OV object view
attached to event, and t time-stamp for E
F.B. Vernadat 47
EM Constructs: Function View
Process: Processes describe the enterprise
behaviour in terms of flows of control (i.e. sequences
of steps)
Core processes (or Domain processes)
Business processes
Formalisation:
P= ?Pid, ? , ? , ? , ES ?
P P P P
Pid process name, ? alphabet or set of steps (i.e. activities) of P, ?
P P
set of triggering conditions c of P (? = {c/ (c ? P)), ? set of
P P
behavioural rules of process behaviour and ES finite set of ending
P
statuses of P
F.B. Vernadat 48
EM Constructs: Function View
Process Behaviour: set of behavioural rules of the ECA form:
WHEN (condition) DO action
- Process triggering rules:
a) to start a process by means of one or more events:
WHEN (START WITH event-i AND event-j) DO EF1
b) to call a sub-process:
WHEN (START) DO EF1
- Forced sequential rules: EF2 must follow EF1 (whatever its
ending status ES(EF1) is "any" is a reserved word):
WHEN (ES(EF1) = any) DO EF2
F.B. Vernadat 49
EM Constructs: Function View
Process Behaviour (cont'd):
- Conditional sequential rules (or branching rules):
Branching conditions in the flow of control
WHEN (ES(EF1) = end_stat_1) DO EF2
WHEN (ES(EF1) = end_stat_2) DO EF3
WHEN (ES(EF1) = end_stat_3) DO EF4
- Spawning rules:
Parallel execution of enterprise process steps (& operator)
(a) Asynchronous spawning:
WHEN (ES(EF1) = value) DO EF2 & EF3 & EF4
(b) Synchronous spawning: (use of SYNC reserved word)
WHEN (ES(EF1) = value) DO SYNC (EF2 & EF3 & EF4)
F.B. Vernadat 50
EM Constructs: Function View
Process Behaviour (cont'd):
- Rendez-vous rules (or flow synchronisation):
To synchronise convergent control flows
WHEN (ES(EF2) = value_2 AND ES(EF3) = value_3 AND
ES(EF4) = value_4) DO EF5
- Loop rules (constructed with conditional rules):
WHEN (ES(EF1) = loop_value) DO EF1
WHEN (ES(EF1) = exit_value) DO EF2
- Process completion rules:
To mark the end of the control flow (use of FINISH reserved word)
WHEN (ES(EF2) = end_stat_x AND ES(EF2) = end_stat_y) DO
FINISH
F.B. Vernadat 51
EM Constructs: Function View
Process Behaviour for ill-structured processes:
AND-case: AND
(do all in whatever order) A B
C D
OR-case: OR
(do some in whatever order) A B
C D
XOR-case: XOR
(do only one on your choice) A B
C D
F.B. Vernadat 52
EM Constructs: Function View
Activity: a process step that is the locus of action
(i.e. it transforms inputs into outputs using resources and time)
Formalisation:
A = ?Aid, FI , FO , CI , CO , RI , RO , ? , ES , Cap , Dmin, Davg,
A A A A A A A A A
Dmax?
Aid activity name, FI , FO , CI , CO , RI , RO function input,
A A A A A A
function output, control input, control output, resource input and
resource output of A, respectively (with FI ? FO ? CI ? ? ; FI
A A A A
? CI = ? ; FI , FO , CI , RO ? 2OV; RI ? 2R; CO ? 2E), ?
A A A A A A A A
activity behaviour (algorithm or script) such that ? (FI , CI , RI )
A A A A
= (FO , CO , RO ), ES finite set of ending statuses, Cap set of
A A A A A
capabilities required by A
ES: A ? ? ES such that ES (A) ? ES
A ? A A A
Dmin, Davg, Dmax: minimum, average, maximum duration of A
F.B. Vernadat 53
EM Constructs: Function View
Operation: elementary action lowest level of
functional granularity
Used in activity behaviour (? )
A
Can be provided by several categories of agents
But is provided by only one agent at run-time
Ex.: move a part, drill a hole, update a database...
Formalisation:
agent.operation-identifier (IN parameters, OUT parameters)
F.B. Vernadat 54
EM Constructs: Resource View
Resource: Enterprise object used as a support in the
execution of an activity
Agent of Functional Entity: active resource (has autonomy)
Component: passive resource (e.g. a tool, a cart, etc.)
Formalisation (of agents):
R = ?Rid, OV , Cap , FO , f ?
R R R R
Rid agent name, OV object view describing properties of
R
resource R, Cap finite set of capabilities offered by
R
resources R, FO set of functional operations of R and f
R R
availability calendar of R
F.B. Vernadat 55
EM Constructs: Resource View
Capability Set: defines a set of capabilities (i.e.
technical characteristics) for technical agents or a set
of competencies (i.e. skills) for human agents
Apply to activities (required capabilities/competencies)
Apply to agents (provided capabilities/competencies)
Categories:
Capabilities Competencies/skills
- Function-related - Knowledge
- Object-related - Know-how
- Capacity-related - Human behaviour &
- Performance-related character traits
F.B. Vernadat 56
EM Constructs: Organisation View
Models the organisational structure of the enterprise.
Enterprise/Divisions/Directions/Departments/Units/Positions
Organisation Unit: lowest level decision centre or
work position (i.e. role) assigned with tasks,
responsibilities and authorities (on objects, agents
and processes/activities)
Organisation Cell: aggregation of organisation units
and/or organisation cells into higher level decision
centre with a manager, responsibilities and
authorities
F.B. Vernadat 57
Example
Customer order processing (one process with three activities):
CustomerCreation
OrderEntryClerk
Create
new
NewCustomerOrder customer
customer
OrderProcessing
OrderEntry System
customer
created
Receive Check Check
START order order customer
OrderProcessing
known FINISH
customer Check Plan Prepare
stock delivery bill
Activity Agent Operation Workflow
F.B. Vernadat 58
Example (cont'd)
FUNCTIONAL ENTITY OrderEntryClerk
Type: Human
InRealLife: M.S. SMITH
ObjectView: OV-31 (* resource description*)
Location: Bldg#1-Office#121
Operations: ReceiveOrder (IN order);
CheckOrder (IN order, OUT: customer);
CheckCustomer (IN customer, OUT status);
CreateCustomer (IN customer, OUT Custid);
NotifyCustomer (OUT message);
ArchiveOrder (IN order)
UpdateCustFile (IN Custid, customer)
FUNCTIONAL ENTITY OrderProcessingSystem
Type: Application
ObjectView: OV-45
Location: ABC/Grieg/OP-appli (UNIX machine)
Operations: CheckStock (IN Sock#, ref#, qty,OUT status);
PlanDelivery (IN order, OUT deliverydate);
CreateMfgOrder (IN order; OUT MfgOrder);
PrepareBill (IN order, OUT customerbill);
SentBill (IN customerbill, OUT customerbill)
F.B. Vernadat 59
Example (cont'd)
OBJECT VIEW Order
RelatedObject: Order
Nature: Information
Properties:
CustomerName: STRING [25].
CustomerAddress: Address;
OrderDate: Date;
ItemLists: List [1:25] of ItemList;
EVENT NewCustomerOrder
Source: External
Timestamp: Arrival (Order)
ObjectView: OV-14 / Order
F.B. Vernadat 60
Example (cont'd)
PROCESS CustomerOrderProcessing
TriggeringEvents: NewCustomerOrder
ProcessBehaviour:
WHEN (START WITH NewCustomerOrder) DO OderEntry
WHEN (ES (OrderEntry) = new-customer) DO CustomerCreation
WHEN (ES (CustomerCreation) = customer-created) DO OrderProcessing
WHEN (ES (OrderEntry) = known-customer) DO OrderProcessing
WHEN (ES (OrderProcessing) = any) DO FINISH
ACTIVITY OrderEntry
FunctionInput: OrderFile
ControlInput: Order
ResourceInput: OrderEntryClerk
FunctionOutput: OrderFile
ControlOutput: {new-customer, known-customer}
MeanDuration: 10 mn
ActivityBehaviour:
{OrderEntryClerk.ReceiveOrder (order);
OrderEntryClerk.CheckOrder (order, customer);
OrderEntryClerk.CheckCustomer (customer, status)}
F.B. Vernadat 61
Part III
Enterprise Modelling Ontologies
F.B. Vernadat 62
Ontology in IT
Ontology is a branch of philosophy about the
essence of things (i.e. what can exist in the world)
In IT, ontology concerns the specification of a shared
conceptualisation in a certain domain (Gruber, 92)
An ontology is a formal description of entities and
their properties, relationships, constraints, behaviours
Nota Bene: Ontology ? Taxonomy ? Thesaurus
Competency of an ontology = questions that the
ontology is able to answer (Fox & Gruninger, 94)
F.B. Vernadat 63
Ontology: A trivial example
Ontology of circles (in geometry):
Definition:
A circle is defined by its center and radius in a 2D space
Formalisation:
Point (X, Y), (X, Y) ? R2 (predicate)
Circle (C1, r) ? C1: Point ? r ? R (properties)
s.t. r > 0 (axiom)
F.B. Vernadat 64
Ontology example (cont'd)
However, a circle can be fully defined as well by:
- Three points P1, P2 and P3 taken on its
circumference such that P1 ? P2 ? P3
- The set of points P (X, Y) that verify its canonical
equation: aX2 + bY2 = c (a, b, c being constants)
Conclusion: an ontology is not necessarly unique for a
given universe of discourse.
F.B. Vernadat 65
Benefits of ontologies
Expressiveness
Formal precision (precise syntax; semantic axioms)
Capitalises on extensive conceptual modelling
experience (e.g. EER, Sowa's conceptual graphs)
Increased cross-application generality and reusability
Support for automated reasoning (rules, logical
inference)
Computationally constraining possible interpretations
of data (intended model)
F.B. Vernadat 66
Ontologies
Different types / generality levels of ontologies:
Foundational (upper) ontology (space-time, part-of, ...)
Domain and task ontologies
Ontology specs express "micro-theories"
Lightweight: top-level structure often in formal diagrammatic
form (e.g. UML-style or semantic networks)
Heavyweight: specified as finite axiom sets in (some subset
of) first-order logic (FOL)
Industry practice: often starts with metadata concept
taxonomies (e.g. STEP, XML e-commerce standards)
but ontology encompasses much more
(Akkermans, 2001)
F.B. Vernadat 67
Ontology of time
Uncertainty on points in time:
time_point (t, min, max) ? min ? t ? max
Partial order relation '<' (respect. '?')
SP(t): start point of interval t; EP(t): end point of t
EQ1: (? t,t',p ,p ,p' ,p' ) strictly_before (t, t') ?
1 2 1 2
time_point(EP(t),p ,p ) ? time_point(SP(t'),p' ,p' ) / p < p'
1 2 1 2 2 1
EQ2: (? t,t',p ,p ,p' ,p' ,p'' ,p'' ,p''' ,p''' ) during (t,t') ?
1 2 1 2 1 2 1 2
time_point(SP(t),p ,p ) ? time_point(EP(t),p' ,p' ) ?
1 2 1 2
time_point(SP(t'),p'' ,p'' ) ? time_point(EP(t'),p''' ,p''' )
1 2 1 2
/ p'' ? p ? p' ? p'''
1 1 2 2
(Gruninger & Fox, 94)
F.B. Vernadat 68
Enterprise Ontologies
Why ontologies are important for EM?
1. Need for a formal enterprise modelling language
2. Need for agreed theoretical foundations
3. Need for knowledge sharing among intelligent
agents / modelling tools
Ontology projects in enterprise modelling:
TOVE project at Univ. of Toronto (Fox & Gruninger)
The Enterprise Ontology, Univ. of Edinburgh (Ushold)
IDEF 5 (KBSI & State Univ. of Texas at Austin)
I* methodology, Univ. of Toronto (Yu & Mylopoulos)
PSL, NIST, USA
F.B. Vernadat 69
CIMOSA Ontology principles
Ontology description method: Two parts:
- Terminology definition: semantic networks or conceptual graphs
- Concept specification: Order-sorted algebra
Sort: Defined by:
- the sort name
- a set of typed variables
- a set of operations on variables
- a set of axioms defining the semantic rules
- a set of relationships defining semantic or relational links of this
concept with other concepts of the ontology
F.B. Vernadat 70
CIMOSA Ontology (cont'd)
Three kinds of links can be used in sorts to relate
ontological concepts to one another:
- semantic relationships
isa link (property inheritance mechanism)
part-of link
- user-defined relationships
named relationships (n-ary)
- terminology relationships e.g. 'is-equivalent-to', 'is-
related-to', 'may-be-related-to', 'is-synonym-to', etc.
F.B. Vernadat 71
CIMOSA Ontology: terminology definition
Organisation Cell
(1,1) belongs to (0,n)
Organisation Unit
(1,n) responsible for (1,1)
(1,n) (1,n) triggers (1,n)
Business Process Event
has
authority on (1,n) (1,1)
(2,2)
(1,1) employs timestamp
bounds
(1,n) (0,n) (0,1)
(0,n) may have
Enterprise Activity Time Point (0,n)
(0,1) requires (1,n) (0,n) input/output (1,n)
(1,n)
Capability needs
Set Object
(1,n)
View
(0,1) provides (1,n)
Resource (1,n)
derived from
(1,n)
Enterprise
HFE AFE MFE Object
is-a link user-defined link
F.B. Vernadat 72
part-of link
CIMOSA Ontology: Concept specification
Event: Events are facts (solicited or not) indicating a change in the
system state.
SORT Event
IMPORT Object_View, Enterprise_Activity, Resource, REAL, BOOLEAN
VARIABLES
Source: Resource ? Enterprise_Activity ? {external}
ObjectView: Object_View
TimeStamp: REAL
OPERATIONS
CreateEvent: Event ? BOOLEAN
Active: Event ? BOOLEAN
AXIOMS
(? e ? Event) CreateEvent (e) ? TimeStamp (e) = SP(e)
(? e ? Event) Active (e) ? defined (TimeStamp(e))
F.B. Vernadat 73
CIMOSA Ontology: Concept specification
Enterprise activity: Enterprise activities are the locus of action, i.e.
they transform an input state into an output state using
resources and time within the course of a process.
SORT Enterprise_Activity
IMPORT Event, Object_View, Resource, LABEL, REAL
VARIABLES
Function_Input: P(Object_View)
Control_Input: P(Object_View)
Resource_Input: P(Resource)
Function_Output: P(Object_View)
Control_Output: LABEL ? P(Event)
Resource_Output: Object_View
Ending_Statuses: P(LABEL)
F.B. Vernadat 74
CIMOSA Ontology: Concept specification
Enterprise activity (cont'd):
Minimum_Duration: REAL
Maximum_Duration: REAL
Required_Capabilities: Capability_Set
Activity_Behaviour: An_Algorithm
Used_By: P(Business_Process)
OPERATIONS
Start: Enterprise_Activity ? BOOLEAN
Finish: Enterprise_Activity ? BOOLEAN
Duration: Enterprise_Activity ? REAL
Ending_Status: Enterprise_Activity ? LABEL
P(S) = power set of S = 2S
F.B. Vernadat 75
CIMOSA Ontology: Concept specification
Enterprise activity (cont'd):
AXIOMS
(? a ? Enterprise_Activity) Function_Input (a) ?
Control_Input (a) ? Function_Output (a) ? ? ?
Function_Input (a) ? Control_Input (a) ? ? ?
Resource_Input (a) ? ? ? Control_Output (a) ? ? ?
Minimum_Duration (a) ? Maximum_Duration (a)
(? a ? Enterprise_Activity) Start (a) ?
defined (preconditions (Activity_Behaviour (a)))
(? a ? Enterprise_Activity) Finish (a) ?
defined (Ending_Status (a)) ?
Ending_Status (a) ? Ending_Statuses (a) ?
Ending_Status (a) ? Control_Output (a)
(? a ? Enterprise_Activity) Duration (a) = EP(a) - SP(a)
F.B. Vernadat 76
TOVE Ontology principles
To support reasoning in industrial environments
Basis for NIST's PSL (Process Specification Language)
The goal of the TOVE (TOronto Virtual Enterprise)
Enterprise Modelling project is to create enterprise
models that not only answer queries with what is
explicitly represented, but also be able to deduce
answers to queries.
Activity ontology
Resource ontology
Cost ontology
Quality ontology
F.B. Vernadat 77
TOVE Activity Ontology
Objectives:
Temporal projection resources and activities
Planning and scheduling
Execution monitoring and external events
Time-based competition
Specification formalism:
First-Order Logic (implemented in Prolog)
Foundations
Situation calculus (Reiter 91)
F.B. Vernadat 78
TOVE Activity Ontology
Situation calculus: is a sorted second order
language with equality
Five domain sorts
respect. for
- action types
- situations
- fluents (or control flows)
- time, and
- arbitrary objects
F.B. Vernadat 79
TOVE Activity Ontology
Situation calculus: provides a semantics to an
ontology of activity and state
- There is an initial situation s0
- The system evolves from one situation s to another s' when
an action a is performed (stochastic automata)
- The structure of situations is that of a tree
(root = s ; each branch = one possible future)
0
- Activity-State model (sub-states allowed)
State Activity State
Es_fabricate enables causes
Fabricate Pro_fabricate
Plug_on_wire Plug_on_wire Plug_on_wire
conjuncts conjuncts
Consume Consume Use Produce Release
wire plug Inject_mold Plug_on_wire Inject_mold
F.B. Vernadat 80
TOVE Activity Ontology
Situation calculus: predicates and axioms
Predicates:
s ? s': denotes that situation s precedes situation s'
Poss (a, s): true if action a can be performed in situation
s
do (a, s): returns the name of situation that results from
performing action a in situation s
do (a, s, s'): denotes that if action a is done in situation s,
then s' is one of the possible situations reached
(complex activities)
actual (s): true if s is the actual situation
occurs (a, s): true when action a is performed from s
F.B. Vernadat 81
TOVE Activity Ontology
Situation calculus: predicates and axioms
Axioms:
S has no antecedent: (? a, s) S ? do (a, s)
0 0
Every situation has a unique predecessor:
(? a , a , s , s ) do (a , s ) = do (a , s ) ? a = a
1 2 1 2 1 1 2 2 1 2
Second-order induction axiom for situations:
(? P) (P(S ) ? (? a, s) (P(s) ? P(do (a, s)))) ? (? s) P(s)
0
The initial situation precedes all other situations:
(? s) ? s < S0
The successor of a situation is later than the situation:
(? a, s , s ) s < do (a, s ) ? (Poss (a, s ) ? s ? s )
1 2 1 2 2 1 2
F.B. Vernadat 82
TOVE Activity Ontology
Situation calculus: predicates and axioms
Notion of causality: what holds after performing an action
Successor state axiom: derives successor state for each fluent
(? a, s) Poss (a, s) ? [holds(R, do (a, s)) ?
?+ (a, s) ? (holds(R, s) ? ? ?- (a, s))]
R R
?+ (a, s) (respect. ?- (a, s)) is a simple formula specifying the
R R
conditions under which an action a asserts (respect. falsifies) the
fluent R.
Occurrence of actions:
actual (S )
0
(? a, s) actual (do(a, s)) ? ?actual (S) ? Poss (a, s)
(? a , a , s) actual (do(a , s)) ? actual (do(a , s)) ? a = a
1 2 1 2 1 2
(? a, s) occurs (a, s) ? actual (do(a, s))
(actions performed along the actual line)
F.B. Vernadat 83
PSL: Process Specification Language
Developed under sponsorship of NIST
International collaboration
Industrial Automation standardisation activity:
ISO TC 184/SC4
Aims:
formal and neutral representation of manufacturing
processes
Interlingua to exchange process information among
industrial applications
F.B. Vernadat 84
What is a process in PSL?
A process is one or more activities that occurs over
a period of time in which objects participate.
PSL
Activity TimePoint Object
Inf- Inf+
F.B. Vernadat 85
PSL Core
Intuition 1:
There are four kinds of entities required for reasoning about
processes -- activities, activity occurrences, timepoints, and
objects.
Intuition 2:
Activities may have multiple occurrences, or there may exist
activities that do not occur at all.
Intuition 3:
Timepoints are linearly ordered, forwards into the future, and
backwards into the past.
Intuition 4:
Activity occurrences and objects are associated with unique
timepoints that mark the begin and end of the occurrence or
object.
F.B. Vernadat 86
PSL Core
Entities
activity
activity-occurrence,
timepoint,
object
Relations
before, between,
beforeEq, betweenEq,
is-occuring-at, participates-in, exists-at
Functions
beginof, endof
F.B. Vernadat 87
Examples of PSL Axioms
Axiom 1 The before relation only holds between timepoints.
(forall (?t1 ?t2) (implies (before ?t1 ?t2) (and (timepoint ?t1) (timepoint
?t2))))
Axiom 2 The before relation is a total ordering.
(forall (?t1 ?t2) (implies (and (timepoint ?t1) (timepoint ?t2)) (or (= ?t1
?t2) (before ?t1 ?t2) (before ?t2 ?t1))))
Axiom 3 The before relation is irreflexive.
(forall (?t1) (not (before ?t1 ?t1)))
Axiom 4 The before relation is transitive.
(forall (?t1 ?t2 ?t3) (implies (and (before ?t1 ?t2) (before ?t2 ?t3))
(before ?t1 ?t3)))
Axiom 9 Everything is either an activity, activity occurrence, timepoint, or
object.
(forall (?x) (or (activity ?x) (activity_occurrence ?x) (timepoint ?x)
(object ?x)))
F.B. Vernadat 88
The Enterprise Ontology
Developed at AI Applications Institute (AIAI), Univ. of
Edinburgh, 1995-1998
Together with IBM
See http://www.aiai.ed.ac.uk/project/enterprise/
Collection of terms and definitions relevant to
business enterprises
The major role of the Enterprise Ontology is to act
as a communication medium, in particular, between:
Different people (users and developers) across diff. enterp.
People and implemented computational systems
Different implemented computational systems (e.g. ERP,
DBMS, spreadsheets...)
F.B. Vernadat 89
The Enterprise Ontology
Ontology organisation:
1. Meta-Ontology and time terms used to define the terms of
the Ontology (e.g. Entity, Relationship, Role) and terms related
to time (e.g. Time-Interval)
2. Activity, Plan, Capability and Resource terms related to
processes and planning (e.g. Activity, Planning, Authority,
Resource, Allocation)
3. Organisation terms related to how organisations are
structured (e.g. Person, Legal Entity, Organisation Unit)
4. Strategy terms related to high level planning for an
enterprise (e.g. Purpose, Mission, Decision, Critical Success
Factors)
5. Marketing terms related to marketing and selling goods and
services (e.g. Sale, Customer, Price, Brand, Promotion)
F.B. Vernadat 90
The Enterprise Ontology: overview
ACTIVITY etc. ORGANISATION STRATEGY MARKETING TIME
Activity Person Purpose Sale Time Line
Activity Specification Machine Hold Purpose Potential Sale Time Interval
Execute Corporation Intended Purpose For Sale Time Point
Executed Activity Partnership Purpose-Holder Sale Offer
Specification
T-Begin Partner Strategic Purpose Vendor
T-End Legal Entity Objective Actual Customer
Pre-Condition Organisational Unit Vision Potential Customer
Effect Manage Mission Customer
Doer Delegate Goal Reseller
Sub-Activity Management Link Help Achieve Product
Authority Legal Ownership Strategy Asking Price
Activity Owner Non-Legal Ownership Strategic Planning Sale Price
F.B. Vernadat 91
The Enterprise Ontology: overview
ACTIVITY etc. ORGANISATION STRATEGY MARKETING TIME
Event Ownership Strategic Action Market
Plan Owner Decision Segmentation Variable
Sub-Plan Asset Assumption Market Segment
Planning Stakeholder Critical Assumption Market Research
Process Specification Employment Contract Non-Critical Assumption Brand
Capability Share Influence Factor Image
Skill Shareholder Critical Influence Factor Feature
Resource Non-Critical Influence Need
Factor
Resource Allocation Critical Success Factor Market Need
Resource Substitute Risk Promotion
Competitor
F.B. Vernadat 92
The Enterprise Ontology: overview
1. Informal EO: the natural language version
Enterprise Activity Example:
"The concept of ACTIVITY is closely linked with the idea of the
DOER, which EXECUTEs an ACTIVITY SPECIFICATION by
performing the specified ACTIVITIES. A DOER may be a
PERSON, ORGANISATIONAL UNIT or MACHINE."
"The ability of a POTENTIAL ACTOR to be the DOER of an
ACTIVITY is denoted by CAPABILITY (or SKILL if the DOER is
a PERSON). ACTORS may have other Roles in respect of an
ACTIVITY such as ACTIVITY OWNER."
F.B. Vernadat 93
The Enterprise Ontology: overview
1. Informal EO: the natural language version
ACTIVITY: something done over a particular TIME
INTERVAL. The following may pertain to an ACTIVITY:
Has PRE-CONDITIONS
Has EFFECT(S)
Is performed by one or more DOERS
Is decomposed into more detailed SUB-ACTIVITIES
Entails use and/or consumption of RESOURCES
Has AUTHORITY requirements
Is associated with and [ACTIVITY] OWNER
Has a measured efficiency
F.B. Vernadat 94
The Enterprise Ontology: overview
2. Formal EO:
Use the Ontolingua language (based on KIF) from Stanford
University, CA
(Define-Frame Activity
:Own-Slots ((Documentation "Something done over a particular Time-Range. The following
may pertain to an Activity:
* is performed by one or more Actual-Doer s;
* is decomposed into more detailed Sub-Activity s;
* Can-Use-Resource s; * An Actor may Hold-Authority to perform it;
* there may be an Activity-Owner;
* has a measured efficiency. ")
(Instance-Of Class) (Subclass-Of Activity-Or-Spec))
:Template-Slots
((Actual-Activity-Interval (Minimum-Cardinality 0) (Cardinality 1)
(Value-Type Time-Range))
(Actual-Pre-Condition (Minimum-Cardinality 1) (Value-Type Pre-Condition))
(Actual-Effect (Minimum-Cardinality 1) (Value-Type Effect))
(Activity-Status (Minimum-Cardinality 1) (Value-Type Activity-State))))
F.B. Vernadat 95
References on EM ontologies
Gruber, T. (1992) Ontolingua: A Mechanism to Support Portable
Ontologies. Res. Rep. KSL-91-66, Stanford Knowledge Systems Lab.,
Final Version, Stanford University, Stanford, CA.
http://www-ksl.stanford.edu
Grr, M. and M.S. Fox (1994) An activity ontology for enterprise
modelling. Third IEEE Workshop on Enabling Technologies:
Infrastructures for Collaborative Enterprises (WET ICE'94),
Morgantown, West Virginia. http://www.ie.utoronto.ca/EIL/
Fox, M.S. and M. Grr (1994) Ontologies for enterprise
integration. Second Int. Conf. on Cooperative Information Systems,
Toronto, May. pp. 82-89.
Benjamin, P.C., C.P. Menzel, R.J. Mayer and N. Padmanaban (1995)
Toward a method for acquiring CIM ontologies. Int. J. of Computer-
Integrated Manufacturing, 8(3): 225-234.
Uschold, M., M. King, S. Moralee and Y. Zorgios (1998) The Enterprise
Ontology. Res., Rep. Artificial Intelligence Applications Institute,
Edingburgh, Scotland, June. http://www.ed.ac.uk/
F.B. Vernadat 96
CONCLUSION
Enterprise Modelling constructs
Significant work already achieved tools available
Existence of norms/standards for well-structured processes
Constructs needed for ill-structured processes
"Soft issues" still poorly addresses (e.g. BP rationale,
skills/competencies, mission, goals, strategic objectives...)
Enterprise Modelling ontology
Still a research area
Which formalism is best?
Can we agree on a common EM ontology?
Or do we have to map different tool/domain ontologies?
F.B. Vernadat 97