Copyright: Copyright (c) 1993-1996 CIMOSA Association.
Citation: CIMOSA Technical Baseline. Version 3.2, March 1996. Copyright (c) 1993-1996 CIMOSA Association. All rights reserved. No part of this document may be reproduced in any form or by any means, electronic or mechanical, for any purpose without the express written permission of CIMOSA Association.


CIMOSA - Title
Version 3.2, Febuary 1996 - CIMOSA Association e.V.

CIMOSA

Open System Architecture for CIM

Technical Baseline - Sections on Business Modelling

(c) all rights reserved CIMOSA Association e.V.


Outline
 CIMOSA Outline

Preface

Table of Contents

Business Oriented Modelling

Model Creation Process

Glossary

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Table of Contents
 CIMOSA Outline

 Table of Contents

 Introduction (who and how to use the document)

 Technical Baseline and its Relation to the AMICE Formal Reference Base

 Structure of the AMICE Formal Reference Base

 Project Glossary Structure

 Business Oriented Modelling

 Architectural Framework

 Enterprise

 CIMOSA Modelling Framework

 CIMOSA Views

 CIMOSA Modelling Levels

 CIMOSA Genericity Levels

 CIMOSA Modelling Object

 CIMOSA Modelling Levels

 CIMOSA Models

 Requirements Definition Model

 Design Specification Model

 Implementation Description Model

 CIMOSA Views

 Function View, Modelling Paradigm Requirements

 Information View, Modelling Paradigm Requirements

 Resource View, Modelling Paradigm Requirements

 Organisation View Modelling Paradigm Requirements

CIMOSA Life Cycle

Enterprise Environments

Requirements Definition Modelling Level - all Views

 RDM Level - Function View

 Function View, Requirements Definition Modelling Level

 Generic Building Blocks of the Function View

 RDM Level - Information View

 Information View, Requirements Definition Modelling Level

 Generic Building Blocks of the Information View

 RDM Level - Resource View

 Resource View, Requirements Definition Modelling Level

 Generic Building Blocks of the Resource View

 RDM Level - Organisation View

 Organisation View, Requirements Definition Modelling Level

 Generic Building Blocks of the Organisation View

Design Specification Modelling Level - all Views

 DSM Level - Function View

 Function View, Design Specification Modelling Level

 Generic Building Blocks of the Function View

 DSM Level - Information View

 Information View, Design Specification Modelling Level

 Generic Building Blocks of the Information View

 DSM Level - Resource View

 Resource View, Requirements Definition Modelling Level

 Generic Building Blocks of the Resource View

 DSM Level - Organisation View

 Organisation View, Design Specification Modelling Level

 Generic Building Blocks of the Organisation View

Implementation Description Modelling Level - all Views

 IDM Level - Function View

 Function View, Implementation Description Modelling Level

 Generic Building Blocks of the Function View

 IDM Level - Information View

 Information View, Implementation Description Modelling Level

 Generic Building Blocks of the Information View

Implementation Description Modelling Level - Resource View

Implementation Description Modelling Level - Organisation View

CIMOSA Model Creation Process

CIMOSA Glossary

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Business Oriented Modelling
 CIMOSA Outline

 Table of Contents

 Business Oriented Modelling

 Architectural Framework

 CIMOSA Modelling Levels

 CIMOSA Views

CIMOSA Life Cycle

Enterprise Environments

Requirements Definition Modelling Level - all Views

 RDM Level - Function View

 RDM Level - Information View

 RDM Level - Resource View

 RDM Level - Organisation View

Design Specification Modelling Level - all Views

 DSM Level - Function View

 DSM Level - Information View

 DSM Level - Resource View

 DSM Level - Organisation View

Implementation Description Modelling Level - all Views

 IDM Level - Function View

 IDM Level - Information View

 IDM Level - Resource View

 IDM Level - Organisation View

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Architectural Framework
 CIMOSA Outline

 Table of Contents

 Business Oriented Modelling

 Architectural Framework

 Enterprise

Physical System of an Enterprise

Decision System of an Enterprise

Information System of an Enterprise

 CIMOSA Modelling Framework

CIMOSA Reference Architecture

CIMOSA Particular Architecture

 CIMOSA Views

Function View

Information View

Resource View

Organisation View

 CIMOSA Modelling Levels

Requirements Definition Modelling Level

Design Specification Modelling Level

Implementation Description Modelling Level

 CIMOSA Genericity Levels

Generic Level

Partial Level

Particular Level

 CIMOSA Modelling Object

Generic Building Block

Building Block Type

Building Block Instance

Building Block Occurrence

(c)  1993 - 1996 CIMOSA Association. All rights reserved


Impressum
CIMOSA Technical Baseline

Impressum

Publisher

CIMOSA Association e.V.

Steinbachstr. 25

D-52074 Aachen/Germany

Managing Editor

Kurt Kosanke

CIMOSA Association e.V.

Stockholmer Str. 7

D-71034 Böblingen

Senior Editor

Francois Vernadat

Univ. de Metz

Production

Manfred Klittich

EEISS

Spessartweg 54

D-65760 Eschborn

Ursula Gröpl

Software and Documentation

Heinrich-Delp-Straße 167a

D-64297 Darmstadt

For ordering information for the full CIMOSA Technical Baseline document see option Order Form in this menue.


Preface
CIMOSA Technical Baseline

Preface

Enterprise operation effectiveness and efficiency is seriously constrained by the inability to provide the right information, in the right place, at the right time. In spite of significant advances in information technology knowledge on availability of information is not readily available and it is still very difficult to access information produced by different applications. The latter is due to the hardware and software incompatibilities of manufacturing and information processing equipment. But it is the lack of knowledge of information availability which presents the major drawback in the use of real time operational wisdom and prevents its use in decision making. Up-to-date enterprise knowledge is a significant business value for the enterprise and its availability would enable to compete more effectively in the marketplace. Therefore, sufficient and timely information access is a prerequisite for its efficient use in enterprise operation.

However relevant knowledge does not only exists inside the enterprise but in the external environment as well. Customers, vendors as well as financial and even governmental institutions add continuously to this knowledge base and to a certain extend have a need-to-know and should be able to directly access parts of the enterprise information base. Therefore information has to be structured and presented in a common and well understood way. Standardization of a common structure and a basic language for representation of the enterprise operation is a pre-requisite for establishing such common understanding in the manufacturing industry and other industries as well.

It has been the aim of the ESPRIT project AMICE (*) to make such common structuring and a compatible business process oriented modeling language available industry-wide. During several ESPRIT contracts the project has developed CIMOSA: Open System Architecture for CIM. The CIMOSA concepts provide operation structuring based on co-operating processes. Enterprise operations are represented in terms of functionality and dynamic behaviour (control flow). Information needed and produced, as well as resources and organizational aspects relevant in the course of the operation are modelled in the process model. However, the different aspects may be viewed separately for additional structuring and detailing during the enterprise engineering process.

CIMOSA supports the complete life cycle of the operational system from requirements capturing to operation and model maintenance. An Integrating Infrastructure aimed at model execution copes with the heterogeneity's of manufacturing and information technology. It provides a set of generic services to be made available system-wide connecting the model with the real-world system components. CIMOSA has been validated through case studies and pilot implementations not only by the ESPRIT project AMICE itself but also by the three ESPRIT Consortia CIMPRES (**), CODE (***) and VOICE (****) with more than 30 industrial and research organisations representing different industry sectors (see page 3). Results from the numerous case studies and from 8 different pilot implementations have contributed to the current state of the CIMOSA Technical Baseline.

This publication amends the book 'CIMOSA: Open System Architecture' published through Springer-Verlag in 1993. For additional reading, providing the current state of the technical specifications on CIMOSA and its application see the list of references on the following page.

for more information please contact:

CIMOSA Association e.V.

c/o K. Kosanke	Tel: (49) 7031 27 76 65

Stockholmer Str. 7	FAX: (49) 7031 27 66 98

D-71034 Boeblingen/Germany	e-mail: Kosanke@IPA.FHG.de

(*) 	AMICE - European CIM Architecture (backward) - see following page for member organisations

(**) 	CIMPRES - CIM Model and Implementation Concept in Precision and Special Tooling Industry

(***) 	CODE - Computer-Supported Enterprise-Wide Data Engineering

(****) 	VOICE & VOICE II - Validating OSA in Industrial CIM Environments by Integration and Implementation

List of Publications

1992

Enterprise Integration Modelling; C.J. Petrie, Editor, Proceedings of the first International Conference, MIT Press 1992, (ISBN 0-262-66080-6)

1993

CIMOSA  -  Open System Architecture for CIM; ESPRIT Consortium AMICE, Springer-Verlag 1993, (ISBN 3-540-56256-7), (ISBN 0-387-56256-7)

Validation of CIMOSA (Open System Architecture) A Joint ESPRIT Projects Report; ESPRIT Projects AMICE, CIMPRES, CODE, VOICE, CIM-EUROPE Conference, Amsterdam, 12-14 May, 1993

CIMOSA - A European Development for Enterprise Integration; K. Kosanke, Manufacturing Automation at the Crossroads - Standardization in CIM Software, IOS Press, 1993, (ISBN 90 5199 137 1)

CIMOSA: Integrating the Production; J. Vlietstra, Conference: Towards World Class Manufacturing, Phoenix/Arizona/USA, September 12-16,1993

CIMOSA: Enterprise Modelling and Enterprise Integration using a Process-Based Approach; F. Vernadat, and

CIMOSA Pilot Implementation for Technology Transfer; W Eversheim, B.R. Katzy, et al.,

JSPE-IFIP WG 5.3 Workshop, The Design of Information Infrastructure Systems for Manufacturing, Tokyo, November 8-10, 1993

OPEN SYSTEM ARCHITECTURE FOR CIM; Esprit Consortium AMICE (Eds.), Research Reports ESPRIT - Project 688 AMICE, Volume 1, (Japanese translation) 1993, printed in Japan, (ISBN 4-526-03335-9)

CIMOSA: Offene System-Architektur; K Kosanke in AW Scheer, Handbuch Informations Management, Gabler 1993, (ISBN 3-409-19938-1)

Computer Aided Enterprise Modelling - A global approach; A. Bienert, D. Schönenberger; Conference Proceedings of the 1993 APMS Conference (IFIP 5.7); Springer-Verlag 1993

1994

CIMOSA - Open System Architecture for CIM, Technical Baseline; CIMOSA Association, private publication July 1994

Special Issue: CIM Architectures; Editor: Prof. H. Wortmann, Computers in Industry - Vol. 24, Nr. 2-3, September 1994

CIMOSA and Manufacturing in Evolution; K. Kosanke, M. Mollo, F. Naccari, C. Reyneri, ESPRIT-CIME, Copenhagen, October 5-7, 1994

1995

Special Issue: Validation of CIMOSA; edited by T. Gransier, W. Schönewolf, Computers in Industry - Vol. 27, Nr. 2, October 1995

CIMOSA - Overview and Status; K. Kosanke, Computers in Industry - Vol. 21, Nr. 2, October 1995

The CIMOSA business modelling process; M. Zelm, F. Vernadat, K. Kosanke, Computers in Industry - Vol. 27, Nr. 2, October 1995

Integrated Manufacturing Systems Engineering; P. Ladet, F.B. Vernadat, Editors, Selected Papers from the ISME'94 - European Workshop on Integrated Manufacturing Systems Engineering, Grenoble, December 12-14, 1994, Chapman & Hall, October 1995 with

Enterprise Engineering with CIMOSA - Application at FIAT; K. Kosanke, M. Mollo, F. Naccari, C. Reyneri, Proceedings of ISME'94, Grenoble, December 12-14, 1994

Architectures for Enterprise Integration; P. Bernus, L. Nemes, T.J. Williams Editors, Findings of the IFAC/IFIP Task Force on Architectures for Enterprise Integration, Chapman & Hall, November 1995

1996

Modelling and Methodologies for Enterprise Integration; P. Bernus, L. Nemes, Editors, Proceedings of EI95, Heron Island, November 8-11, 1995, Chapman & Hall, to be published May 1996 with

Process Oriented Presentation of Modelling Methodologies; K. Kosanke,

CIM Business Process and Enterprise Activity Modelling; F. Vernadat, and

Objects and Environments in Dynamic CIMOSA Models; I.L. Kotsiopolous.

Enterprise Modelling and Integration; F. Vernadat, INRIA Lorraine, France, Chapman & Hall, to be published July 1996

Contributions of CIMOSA to GERAM; K. Kosanke, F. Vernadat, submitted to IFAC World Congress 96, San Francisco, June 30-July 5, 1996

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Introduction
CIMOSA Technical Baseline

Introduction (who and how to use the document)

Intended Readership: Technical Professionals interested and involved in enterprise integration and enterprise modelling.

The document 'CIMOSA Technical Baseline - Sections on Business Modelling' is based on the AMICE Formal Reference Base as contained in the ESPRIT project 1994 M-3 Deliverables and the Technical Baseline version 3.0 published by the CIMOSA Association e.V. in 1994. The Technical Baseline has been re-edited adapting it for the hypertext requirements and modifying some of the items in their sections 1.2 Terms and Definitions. In addition the version 3.2 contains up-dates especially of the sections on resource and organisation view. This document is entirely relating to Business Modelling as contained in Part I of the Technical Baseline and the relevant entries of the glossary of Part V. It leaves out Part II (IT Modelling including the items on the IIS) and Part III (formal descriptions e.g. EXPRESS). The complete Technical Baseline is still available from the CIMOSA Association.

The AMICE project documentation of technical specifications is captured in the form of "Items" in the AMICE Formal Reference Base. The CIMOSA technical specification have been validated through project case studies and applications in the AMICE project as well as in co-operating ESPRIT projects (CIMPRES, CODE and VOICE). It is the reference for future use of CIMOSA and thereby subject to further validation through implementation by any party involved in CIMOSA. Results from ongoing work will be used to further improve and extend the CIMOSA specifications leading to further updates of the CIMOSA Technical Baseline in the future.

This document contains a short introduction describing the overall structure of the CIMOSA Technical Baseline and relating it to the AMICE Formal Reference Base. The introduction is followed by a representation of the structure of the AMICE Formal Reference Base identifying the different parts available in the CIMOSA Technical Baseline. This part also includes a presentation of the layout of the items as represented in the Technical Baseline in which the technical specifications have been captured.

Business oriented modelling is represented on the basis of the 'CIMOSA Architectural Framework'. Starting with an general overview of its contents, the different parts of the Architectural Framework are shown in the sections on 'CIMOSA Modelling Levels' and 'CIMOSA Views'. Further details on CIMOSA business oriented modelling can be found in the sections 'Requirements Definition Modelling', 'Design Specification Modelling and 'Implementation Description Modelling'. A glossary complements the technical specifications of CIMOSA.

The hyperlinks introduced in the different sections provides the reader with easy navigation through the document. These links provide access to more detailed information on keywords identified in the Terms and Definition section of the different items of the Technical Baseline.

The sections on the 'CIMOSA Life Cycle' and 'Enterprise Environments' as well as two subsections on the 'Implementation Description Modelling' section are not yet available. This is also the case for the part on the 'CIMOSA Model Creation Process'. On the latter the current state has been published recently in a paper in Computers in Industry. Further work on CIMOSA will make this material available in future versions of the CIMOSA Technical Baseline.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Technical Baseline and its Relation to the AMICE Formal Reference Base
CIMOSA Technical Baseline

Technical Baseline and its Relation to

the AMICE Formal Reference Base

As the Technical Baseline is based on the AMICE Formal Reference Base the following Table provides the relations between the two Structures. The AMICE Formal Reference Base is structured into sets of items, each set addressing a particular part of CIMOSA. Details of this part are provided by the individual items which identify, specify and describe the different subjects using a common format (see Chapter Structure of the AMICE Formal Reference Base ).

Part I - Business Oriented Modelling

Section I-1: Architectural FrameworkSection I-2: CIMOSA Modelling Level Section I-3: CIMOSA Views Section I-4: CIMOSA Life Cycle Section I-5: CIMOSA Enterprise Environments Section I-6: Requirements Definition Modelling Level Section I-7: Design Specification Modelling Level Section I-8: Implementation Description Modelling Level	B0-series of items  B5-8 series of items (derived from Bxx-series of items) B1-4 series of items not yet available not yet available B11-41 series of items (all Views) B12-42 series of items (all Views)  B13-43 series of items (two Views not yet available)
Part II - IT Oriented Modelling

Section II-1: Information View - General and RDM Level Section II-2: Information View DSM Level Section II-3: Information View IDM Level Section II-4: IIS Concepts and Structure Section II-5: IIS Services	B2-21 series of items B22-series of items B23-series of items C-4 series of items C-5-series of items
Part III - Formal Representation

Section III-1: Modelling Constructs (Set Notation) Section III-2: Modelling Constructs (EXPRESS Notation) Section III-3: IT Oriented Modelling (ERA Notation) Section III-4: CIMOSA Naming Convention	B1-2100 item B11-42 series of items B2-2200 item B0-6000 item
Part IV - CIMOSA Model Creation Process (tbd)

Part V - CIMOSA Glossary

relevant entries	relevant entries

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Structure of the AMICE Formal Reference Base
 CIMOSA Technical Baseline

Structure of the AMICE Formal Reference Base

1.	Top Level Categories

The Formal Reference Base (FRB) is structured at the top level into the following six main categories.

CAT A CAT B CAT C CAT D CAT E CAT F	AMICE Project General (not part of Technical Baseline) CIMOSA Modelling Framework CIMOSA Integrating Environments CIMOSA System Life Cycle CIMOSA Releases and Standards (not part of Technical Baseline) Development of CIMOSA (not part of Technical Baseline)
Referring to the table above, these categories and their next lover level structure are:

Category A - AMICE Project General (not part of the technical base line): These FRB items describe the overall AMICE Project objectives and how CIMOSA satisfies these objectives.

Category B - CIMOSA Architectural Framework, Modelling Concepts and Constructs: These items describe the Framework and its contents; Genericity levels, Modelling levels, Views and set of modelling constructs.

Category C0/3 - CIMOSA Environments: These Items describe CIMOSA Environments Structure and Relations and the content of the various CIMOSA Environments; Enterprise Engineering Environment, Enterprise Operations Environment and Enterprise Physical Environment

Category C4/5 - CIMOSA Integrated Infrastructure: These Items describe the Integrated Infrastructure and its services

Category D - CIMOSA System Life Cycle: This category of Items describes the methodology of using CIMOSA through the Model Creation Processes and the System Life Cycle.

Category E - CIMOSA Release Plan and Standards (not part of the technical base line): These Items cover definitions of the CIMOSA release plan, migration issues, specifications of the releases, and the overall positioning of CIMOSA towards international standards.

Category F - Development of CIMOSA (not part of the technical base line): These Items describe the general AMICE development strategy for CIMOSA, the AMICE documentation structure, standards and change control procedures, and general project operational procedures.

2	Item Numbering and Item Series Structure

All Item identifiers (id) follow the format:

Css-nnnn

where,

-	C is the FRB category letter (one of 'A' through 'F' - see above);

-	ss is the one- or two-digit series number within an FRB category ('0', '1', '2',..., '10', '11', '12',...); and

-	nnnn is the four-digit number of the Item within a given series.

The four digit Item numbers are allocated in such a way as to make clear the relative levels of documentation detail between a group of Items. For example those Items numbered 1100, 1200, 1300, etc., all address sub-topics of those identified in the Item numbered 1000 and at a greater level of detail than Item 1000.

This structure has been changed for the Technical Baseline in order to improve readability.

3.	Item Format

<name>

<id>. Version: <#>; Last Update: <date>

1.	Technical Section

1.1	Purpose and Scope <text>

1.2	Terms and Definitions

(1) <Term>:

<definition a>

<definition b>

...

(2) <term 1>: <definition>

(3) <term 2>: <definition>

1.3	Abbreviations and Acronyms

<xxx>:	<text>

1.4	Description

<text>

1.5	Template

<text>

<CONSTRUCT>

Header
Type: Identifier: Name: Design Authority: Operation Responsibility : Operation Authority :	relevant category - select from list <construct> - unique identifier name of the <construct> instance in the form of <adjective> <noun> <identifier> / <name> of Organisation Unit with authority to design/maintain this particular instance] <identifier> / <name> of Organisation Unit with responsibility for operation of this particular instance] <identifier> / <name> of Organisation Unit with authority for operation of this particular instance]
Body
A. Descriptional Properties:  <item>: ... B. Relational Properties: <item>: ...	[text]  [text]

2.	Background Section

2.1	Examples (not applicable) or

<text>

2.2	Document References (none) or

<ordered list>

2.3	Open Issues (none) or

<ordered list>

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Project Glossary Structure
CIMOSA Technical Baseline

Project Glossary Structure

The project glossary gives an overview of the definitions used in the CIMOSA specifications (Formal Reference Base Items). The definitions have been derived from the FRB items as defined in their section 1.2 (see page 5) and are given in alphabetic order. Source document is the FRB item identified by its id number as used in this document.

The glossary is structured according to the following layout:

<Term>

Abbreviation: <xxx>

Source Document: <FRB id>

<term definition>

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Enterprise
CIMOSA Technical Baseline

Enterprise

B0-1000. Version: 4.1; Last Update: 94.06.22

1.	Technical Section

1.1	Purpose and Scope

Defines the entire business of a manufacturing enterprise and identifies the major sub-systems of any enterprise.

1.2	Terms and Definitions

(1) 	Enterprise: a set of management, operational and support processes and functions, and a set of physical and human resources, all supported by financial resources, executing activities for the purpose of producing goods or services.

(2)	Manufacturing Enterprise:

(a)	an Enterprise entity created for the purpose of producing manufactured goods from raw materials or basic components.

(b)	any manufacturing Enterprise is composed of three major sub-systems: a Physical System, a Decision System and an Information System. (See Figure B0-1000/1). These sub-systems are highly interrelated and any enterprise model describing any of the subsystems has to recognise these relations.

Figure B0-1000/1: Overall Structure of any Enterprise

1.3	Abbreviations and Acronyms (none)

1.4	Description

1.4.1	Generalities

Enterprises are physical industrial entities built to produce goods or services to respond to some customer needs. They are highly dependent on market needs and customer satisfaction. Enterprises must face two dynamic environments (*):

-	The external environment characterised by fast changing market needs and competition from other vendors, and

-	The internal environment characterised by global objectives, management attitude, and technological changes.

Figure B0-1000/1 illustrates the fact that any manufacturing Enterprise can be broken up into three major subsystems: the Physical System (where the action is), the Decision System (the control structure) and the Information System (data processing and data repository).

2.	Background Section

2.1	Examples

Examples of types of discrete parts manufacturing enterprises for which CIMOSA principles can be applied include but are not limited to:

-	Mass production: Dedicated production of large quantities of one product (with limited model variations). Examples include manufactures of electronic chips, electronic devices, automobiles, appliances, etc.

-	Batch production: Production of medium lot sizes of the same product or component. The lots may be produced once or repeated periodically. Examples include producers of books, clothing, and certain industrial machinery.

-	Job shop production: Production of low quantities (one of a kind), of specialised products. Products are often customised and technologically complex. Examples include manufacturers of airplanes, machine tools, etc.

2.2	Document References (none)

2.3	Open Issues (none)

(*) 	Note: Due to the high-level of generality of the Enterprise term, it will be written with capital or lower case letters in CIMOSA documents.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Physical System of an Enterprise
CIMOSA Technical Baseline

Physical System of an Enterprise

B0-1100. Version: 4.1; Last Update: 94.06.22

1.	Technical Section

1.1	Purpose and Scope

Defines the physical part of a manufacturing enterprise.

1.2	Terms and Definitions

(1)	Physical System of a manufacturing Enterprise: represents the set of physical resources and pieces of equipment, the materials and goods, the human resources, and the physical Enterprise infrastructure used to transform raw materials or components into finished products.

1.3	Abbreviations and Acronyms (none)

1.4	Description

The Physical System of an Enterprise is what one can see or can touch. It is recorded in the capital asset register of the company. It includes the buildings, lands, pieces of equipment (owned or rented), physical resources, materials in stock, goods of any kind, computer facilities (including hardware and software), data storage media and human resources. The execution of enterprise operations is also part of the Physical System. Central to the control of these operations are resource management and operations management which rely on good modelling of the resources and of the functions.

2.	Background Section

2.1	Examples

The Physical System of a small manufacturing enterprise consists of its buildings and properties, its people, its machinery, its resources of any kind (tools, transportation devices, equipment, etc.), its physical inventories (raw materials, semi-finished items, finished products, sub-assemblies, consumables, etc.).

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Decision System of an Enterprise
CIMOSA Technical Baseline

Decision System of an Enterprise

B0-1200. Version: 5.2; Last Update: 94.06.22

1.	Technical Section

1.1	Purpose and Scope

Defines the decision-making part of a manufacturing enterprise.

1.2	Terms and Definitions

(1)	Decision System of a manufacturing Enterprise: represents the set of predictive, administrative, planning, control and maintenance processes necessary to perform day-to-day operations of the Physical System.

(2)	Decision Level of a Decision System of an Enterprise: made of a certain number of Decision Centers and is characterised by its planning horizon and the level of abstraction of its model (in terms of aggregation of data, entities and criteria to be optimised).

(3)	Decision Center of a Decision Level: a functional entity of the enterprise which can make decisions for a given horizon on the basis of information about the enterprise or its environment.

(4)	Horizon: time scale on which decisions can be taken with a determined degree of confidence.

1.3	Abbreviations and Acronyms

AMRF:	Advanced Manufacturing Research Facilities

ISO:	International Standards Organisation

NIST:	National Institute of Standards and Technology

1.4	Description

Figure B0-1200/1: Hierarchical Decision System of an Enterprise

The Decision System of an Enterprise is the mind of the Enterprise. It plans, controls and monitors the Physical System operations. It is composed of the set of all management processes and activities constraining and controlling the Physical System operations. It makes decisions on the basis of information extracted from the Information System which has gathered information either from the external world or via interaction with the Physical System. The Decision System is associated to a control structure. It is usually structured into a hierarchy of decision levels. Each level is characterised by a planning horizon and a number of decision centers. The higher the level in the hierarchy, the longer the horizon and the fewer decision centers. Decision Systems of manufacturing Enterprises can be structured according to a hierarchy made of, for instance, five levels: the corporate level, the plant or factory level, the section or area level, the cell or station level and the equipment or process level (Figure B0-1200/1). In CIMOSA, the Decision System of an Enterprise is mostly modelled in the Function View and in the Organisation View, and to some extent in the Information View (e.g. integrity rules, knowledge, etc.).

2.	Background Section

2.1	Examples

Types of Decision-making activities (*):

-	Time deterministic and mechanism deterministic decision (Business Process(es) within the Domain Process).

-	Time deterministic and mechanism non-deterministic decision (as transfer control via organisation constructs to the human entity).

-	Time non-deterministic and mechanism deterministic decision (automatic transfer control to another Domain Process which handles the out-of-line situation).

-	Time non-deterministic and mechanism non-deterministic decision can be coded as transfer control via organisation constructs to human entity.

Example 1: The Decision System of a small manufacturing enterprise is the set of all its decision-making centers concerning personnel management, sales, marketing, finance, accounting, master production scheduling, Materials Requirements Planning, capacity planning, production scheduling, product design and product engineering, process planning, part programming, production dispatching, inventory control, shop-floor control, quality assurance and quality control, shipping and receiving, plant maintenance.

Example 2: The control structure as developed by the Advanced Manufacturing Research Facility (AMRF) of the National Bureau of Standards (now NIST) provides a framework for development of hierarchical decision systems for manufacturing shop-floor control activities (Jones and McLean, 1986) and has been extended in other works (ISO, 1988; CIM Reference Model Working Group, 1987; Graefe and Thomson, 1989).

2.2	Document References

1.	CIM Reference Model Working Group, 1987. Technical Report on CIM Reference Model. ISO/TC 184/SC5/WG1.

2.	Graefe, U and Thomson, V. 1989. A Reference model for production control. Int. J. of Computer Integrated Manufacturing, Vol. 2, No. 2, pp. 86-93.

3.	Doumeingts, G., 1984 Method GRAI: Méthode de Conception des Systèmes de Productique. Thèse d'Etat, University of Bordeaux, France

4.	ISO. 1988. ISO Reference Model for Shop Floor Production Standards. ISO/TC 184/SC5 TR. 10 314.

5.	Jones, A. and McLean, C. 1986. A proposed hierarchical control model for automated manufacturing systems. Journal of Manufacturing Systems, Vol. 5, pp. 15-25.

2.3	Open Issues (none)

(*)	as used in CIMOSA models

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Information System of an Enterprise
CIMOSA Technical Baseline

Information System of an Enterprise

B0-1300. Version: 4.2; Last Update: 94.06.22

1.	Technical Section

1.1	Purpose and Scope

Defines the information part of a manufacturing enterprise (i.e. data and knowledge produced, stored, maintained and processed in the enterprise).

1.2	Terms and Definitions

(1)	Information System of an Enterprise: the part of the enterprise representing the processes and functions for short term and long term data and information processing/storage/maintenance according to the needs of users and applications of the Decision System and the Physical System of the Enterprise.

(2)	Data: made up of two things: a fact (i.e. a value) and a meaning.

(3)	Information: the meaningful interpretation and correlation of some aggregation of data in order to allow one to make decisions or to communicate.

(4)	Database: a large collection of interrelated data logically stored on a mass storage system to be accessed and shared by various users or applications of some Enterprise.

1.3	Abbreviations and Acronyms (none)

1.4	Description

Any Enterprise has an Information System which constitutes its know-how, its memory. The Information System can be informal (verbal information exchanges, unstructured documents, etc.), formal (formatted information documents and information exchanges), or computerised (in the form of a file system or a database system). For the Particular Enterprise, the Information System is composed of all pieces of information produced, used or stored in the Enterprise (data, messages, documents, computer screens, files, etc.), their relationships or associations, the constraints applied to them, and their processing. Data and information maintained in the Information System are required to perform current enterprise operations, to report on past operations and to plan for future ones. They provide support all over the System Life Cycle and Product Life Cycle.

The part of the Information System of an Enterprise which is computerised by means of a database management system is called the enterprise database.

Data and information are two words that are very often used interchangeably in common usage. However, they have different meanings in information processing and must be distinguished (Appleton, 1984).

2.	Background Section

2.1	Examples

The Information System of a small manufacturing enterprise is the set of all its customer data, product data, supplier data, customer order data, procurement order data, production data, inventory data, process plans, etc.

2.2	Document References

1.	D.S. Appleton, The CIM Database, Computer-Integrated Manufacturing Series, Vol. 1, No. 4. CASA/SME, Society of Manufacturing Engineers, Dearborn, MI.

2.	L. Sartori, Manufacturing Information Systems, Addison-Wesley, Reading, MA, 1988.

3.	A-W. Scheer, Enterprise-Wide Data Modelling, Springer-Verlag, Berlin, 1989.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


CIMOSA Modelling Framework
CIMOSA Technical Baseline

CIMOSA Modelling Framework

B0-2000. Version: 5.4; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Defines the CIMOSA Reference Architecture and a comprehensive framework within which to structure a compliant CIMOSA Particular Architecture providing semantic unification within a manufacturing enterprise.

1.2	Terms and Definitions

(1)	Modelling Framework: identifies a collection of elements needed for modelling tasks.

(2)	CIMOSA Modelling Framework (*):

(a)	provides a common structure for semantic unification within enterprises in the form of:

-	the CIMOSA Reference Architecture, provides building blocks/constructs for enterprise modelling.

-	the CIMOSA Particular Architecture, created for the particular enterprise using the Reference architecture.

(b)	represented by a three-dimensional structure, whose orthogonal axes define the CIMOSA Model Creation Processes, accross the CIMOSA Modelling Levels, CIMOSA Views and CIMOSA Genericity Levels and are:

-	the (Stepwise) Instantiation Axis, controlled particularisation process from generic to particular.

-	the (Stepwise) Derivation Axis, controlled specification process from requirement to implementation.

-	the (Stepwise) Generation Axis, controlled visualisation of specific aspects of the enterprise.

(c)	applied and maintained through the definition and use of CIMOSA Environments.

-	Enterprise Engineering Environment, model creation and maintenance.

-	Enterprise Operation Environment, model application in enterprise operation control and monitoring.

1.3	Abbreviations and Acronyms

CEN/CENELEC:	Comité Européen de Normalisation/-"- Electro-technique

CIM:	 	Computer Integrated Manufacturing

ENV:	European Norm

1.4	Description

The aim of the CIMOSA Modelling Framework for enterprise modelling is to provide a structured and semantically unified set of languages supporting enterprise description and integration. This means that in order to integrate two components of a CIM system (be they applications or machines or humans), these components have to share a common definition of the objects that they exchange (in other words, they must "talk" compatible languages). Therefore, there is the need for a common referential (or semantic unification mechanism) for enterprise integration in addition to an integrating infrastructure. This is what the CIMOSA Modelling Framework is about for the part of the enterprise to be analysed and integrated.

Figure B0-2000/1: The CIMOSA Modelling Approach

The need for modelling a CIM enterprise and its associated CIM system in a coherent way has generated a modelling approach based on a Reference Architecture from which Particular Architectures can be developed. By applying the architectural principle of modularity, a three dimensional representational structure has evolved, whereby its three axes serve to:

(a)	classify, separate and define the (possibly conflicting) considerations and processes used to develop Particular Architectures from the Reference Architecture;

(b)	provide a basis for identifying the major components (sets of constructs) of the CIMOSA Modelling Framework.

This is illustrated by Figure B0-2000/1. CIMOSA is applied to specific manufacturing enterprises through the application of Model Creation Processes (D0-series of items).

The classifications associated with the (Stepwise) Generation Axis are termed Views, and comprises the Function View, the Information View, the Resource View and the Organisation View. The purpose of this axis is to emphasise the fact that an Enterprise must at least be modelled in terms of functions (of its Decision and Physical Systems) which require/use data and information (of its Information System) as well as materials, components and resources (of its Physical System) and operate under established responsibilities (as part of the Decision System).

Figure B0-2000/2: Overview of the Modelling Framework

The classifications associated with the (Stepwise) Derivation Axis are termed Modelling Levels, and comprise the Requirements Definition Modelling Level, the Design Specification Modelling Level and the Implementation Description Modelling Level. The purpose of this axis is to impose a structured approach in the development of an implementation model which is derived from the definition of the requirements.

The classification associated with the (Stepwise) Instantiation Axis are termed Genericity Levels, and comprise a Generic Level, a Partial Level and a Particular Level. The purpose of this axis is to enforce use of common descriptive languages (defined by Generic Building Blocks), enforce the use of standard components and enforce re-use of existing Partial Models whenever possible to reduce model development cycle times.

Creation and maintenance of the various CIMOSA models is done in the enterprise engineering environment in which the Model Creation Processes are applied. Model application are in the enterprise operation environment either as decision support tool in management and planning processes or in model driven enterprise operation monitoring and control. and the environments in which they are implemented are termed Environments.

For reference purposes throughout the B0-series of items, Figure B0-2000/2 summarises the overall structural framework of CIMOSA.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC. 1990. Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling. European Pre-standard ENV 40 003.

2.3	Open Issue (none)

(*)	ENV 40 003

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


CIMOSA Reference Architecture
CIMOSA Technical Baseline

CIMOSA Reference Architecture

B0-2100. Version: 5.3; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Contains a set of Generic Building Blocks, Building Block Types, Partial Models and guide-lines from which to model a manufacturing enterprise and its associated CIM system.

1.2	Terms and Definitions

(1)	Reference Architecture: an intellectual paradigm which facilitates discussion, analysis and specification of a given area of discourse.

(2)	CIMOSA Reference Architecture:

(a)	definite base from which CIMOSA Particular Architectures may be created. It consists of defined, extendible, sets of:

-	Generic Building Blocks and Building Block Types defined as object classes;

-	Partial Models;

-	existing and allowable relationships between the modelling constructs;

-	rules and constraints governing the application of the modelling constructs and Partial Models for specific use (i.e. creation of Particular Architectures).

(b)	structured into two main Genericity Levels:

-	the Generic Level; and

-	the Partial Level.

(3)	Generic Building Block: a generalisation (abstraction) of all Building Blocks (Types, Partial, Particular) instantiated from it. It contains a minimum set of attributes common to all Building Blocks (Types, Partial, Particular) instantiated from it.

(4)	Building Block Type: specialisation of a Generic Building Block or a more generic Building Block Type.

(5)	Building Block: component of a Partial or Particular Model. A building block instance is a user-defined construct type, defined as an instance of either a Generic Building Block or a Building Block Type. It is populated by building block occurrences.

(6)	Partial Model defined by means of:

(a)	a set of building blocks defined as partial instances of Building Block Types or Generic Building Blocks, which are related to each other;

(b)	configuration rules, which define which combination of building blocks a Partial Model is allowed to contain; and

(c)	consistency rules, which define which relationships are allowed in a consistent model.

(7)	Building Block Component: Presently the term component is used as defined in the Oxford Dictionary of Current English being a constituent of a larger entity.

(8)	Construct (*): a general term to cover components of Generic Building Blocks, Generic Building Blocks, Building Block Types, Partial Models, Particular Models as well as their instances.

(9)	Object Class: specifies the structure (**) of similar objects representing modelling constructs. It consists of a list of elements (***) and possibly rules constraining elements. It is identified by a name.
An object class is like a type in programming languages and can be described in the form of a template from which objects or sub-types can be created.

(10)	Element is a component of the class structure; an element of an object class. It has a name and can be:

(a)	a descriptive property or attribute (single valued or multi valued).

(b)	a component object class (referenced by its name)

(c)	a relation property or attribute; i.e. a link to another object class

(d)	a structure defined by its own syntax (e.g. procedural statements)

1.3	Abbreviations and Acronyms

CIM: 	Computer Integrated Manufacturing

ENV: 	European pre-Norm

1.4	Description

The CIMOSA Reference Architecture contains the whole set of constructs (i.e. object classes and partial models) required to describe the architectural solution for a particular manufacturing enterprise, the latter of which is to be captured in the form of a CIMOSA Particular Architecture (ENV 12 204). It also contains the guidelines (rules and constraints) for instantiation, derivation and generation needed both in the generic context of a CIMOSA reference and standardisation framework, and in the specific context of a particular enterprise planning to define and implement its own CIM system.

The set of modelling constructs and relationships in the Reference Architecture can be likened to a natural language dictionary and phrase-book: they are the formal, extendible definitions and descriptions of the elements of the CIMOSA 'modelling language', and are a synthesis of the generic characteristics of those appearing in specific models, and are thus applicable to a wide range of enterprises. These generic constructs do not imply any form of rigid structure or relationship, but instead provide the means by which such structure can be expressed in a common manner, and can be assembled to specific models during the model creation processes. The rules and constraints associated with the model creation processes can similarly be likened (following the natural language analogy) to a grammar. They govern the way in which the modelling constructs can and cannot be used to be compliant with the architecture.

The Reference Architecture is structured into two main parts called Genericity Levels: one containing the Generic Building Blocks and Building Block Types (termed the Generic Level), and one containing Partial Models or 'macro-constructs' (termed the Partial Level) derived from the former. Both of these parts are used in developing Particular Architectures (via CIMOSA Model Creation Processes, which are performed within the CIMOSA Enterprise Engineering Environment).

Figure B0-2100/1: Mapping Between CIMOSA and Object-Oriented Terminology

1.4.1 CIMOSA Meta-Model

CIMOSA modelling concepts have been designed to be in line with the generic object-oriented approach for systems modelling (Rumbaugh et al., 1991).

The object-oriented approach defines the concept of 'object' as the most generic concept for everything, where an object is defined by a unique identifier and by an instantiation of its 'object class'.

An object class is a set of similar objects. It is defined by a name, a set of descriptive properties or 'elements' which can themselves be objects (defining the object state) and a set of procedural attachments or 'methods' (defining the object behaviour). Object classes can be organised into class hierarchies where generic classes (super-classes) can be specialised into more detailed classes (sub-classes). Sub-classes inherit properties and methods of their super-classes, add new properties or methods and can overwrite inherited ones.

In CIMOSA, let us call the root object the CIMOSA Object Class. It is defined by a set of properties called elements (either data entries or reference to another object class). Some of these elements are the Building Block Components, meaning that they have a special structure or syntax imposed by CIMOSA (e.g. tabular form, language, etc.). The first level below CIMOSA Object Class are the so-called Generic Building Blocks, which are the most generic object classes defined in the CIMOSA Reference Architecture. These generic object classes can be specialised into Building Block Types, which are documented, classified types (****) of constructs of the CIMOSA Reference Architecture.

Partial and particular Building Block Instances are user-defined object classes defined as specialisations of Generic Building Blocks or Building Block Types for the needs of Partial or Particular Models. Finally, actual objects or enterprise entities are occurrences of object classes, called Building Block Occurrences.

Figure B0-2100/2: Structure for CIMOSA Constructs

While the object-oriented approach uses the words instance and occurrence interchangeably, CIMOSA needs to differentiate between instances and occurrences because of the distinction between the Enterprise Engineering Environment (intentional part) and the Enterprise Operation Environment (extentional part) of the enterprise. Figure B0-2100/1 provides the mapping between CIMOSA structuring concepts and the object-oriented terminology. Figure B0-2100/2 provides examples of object classes and elements.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/TC310/WG1 1995. Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling. ENV 12 204.

2.	J. Rumbaugh et al. Object-Oriented Modelling and Design, Prentice-Hall, Englewood Cliffs, NJ, 1991.

2.3	Open Issues

1.	The terminology used in the CIMOSA Reference Architecture is subject to future change to comply with the terminology defined by standardisation bodies (and especially the terminology of ENV 40 003).

(*)	ENV 12 204

(**)	in the classical object oriented literature object class also defines the behaviour of objects by means of procedures called methods.

(***)	an object class is a set of like objects. Element is used here with the meaning of "a component of" and not an instance in a set (called object).

(****)	Object classes and types are used here with the same meaning.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


CIMOSA Particular Architecture
CIMOSA Technical Baseline

CIMOSA Particular Architecture

B0-2200. Version: 5.2; Last Update: 96.02.24

1.	Technical Section

1.1	Purpose and Scope

Contains a model of the CIM system for a particular manufacturing enterprise derived from the CIMOSA Reference Architecture.

1.2	Terms and Definitions

(1)	Particular Architecture: organized set of elements with clear relationships forming a particular whole.

(2)	CIMOSA Particular Architecture:

(a)	defines the architectural solution for a specific manufacturing enterprise in a form derived directly from the CIMOSA Reference Architecture, conditioned by the needs and requirements of that specific enterprise.

(b)	It is represented in the Particular Level of the CIMOSA Particular Framework. The CIMOSA Particular Architecture is created by using Building Block Instances from which Building Block Occurrences are generated in the course of enterprise model processing.

1.3	Abbreviations and Acronyms

CIM: Computer-Integrated Manufacturing

1.4	Description

In developing models for his own enterprise, a CIM user will start by translating his/her business and operational objectives into a set of CIM system requirements. These requirements will be restructured (e.g. in order to identify a stable base for evaluating/permitting changes) and various levels of design established before finally deriving a definition of the required implementation. To perform these activities in an efficient and cost-effective manner, and to ensure that the resulting implementation both (1) adequately reflects the underlying requirements, and (2) is amenable to subsequent modifications to those requirements, the user requires a comprehensive design methodology and a set of understandable constructs to express the results and evolution of various stages of the development.

The results of the development process are expressed in the form of a CIMOSA Particular Architecture, which is then implemented according to specifications of the CIMOSA Enterprise Engineering Environment, and residing in and controlling the Enterprise Operation Environment of the enterprise. A given Particular Architecture will evolve over time as changes in the enterprise's requirements occur, but at any time is based on a set of (instantiated) reference constructs (i.e. instantiated from Generic Building Blocks, Building Block Types and/or Partial Models), and supported by the CIMOSA methodology (CIMOSA Model Creation Processes and CIMOSA Modelling Constraints), defined within the CIMOSA Reference Architecture. The methodology itself and the Particular Architecture are respectively applied in, and created with the aid of, the CIMOSA Enterprise Engineering Environment.

2.	Background Section

2.1	Examples (tbd)

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


CIMOSA Views
CIMOSA Technical Baseline

CIMOSA Views

B0-3000. Version: 5.3; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Defines the different views which are useful to focus on specific aspects of integrated enterprise models discarding others.

1.2	Terms and Definitions

(1)	Modelling View: an abstraction viewpoint of one total model, which emphasises some particular aspects of the model and disregards others for ease of analysis. A Modelling View is described by a set of constructs.

(2)	CIMOSA Views: defined in the CIMOSA Architectural Framework defines, along its Stepwise Generation Axis, four Views:

-	Function View,

-	Information View,

-	Resource View

-	Organisation View

1.3	Abbreviations and Acronyms (none)

1.4	Description

There is a considerable number of kinds of requirements to a CIM system. Many of these require different means of expression, and are designed and implemented in different ways. Without a viable structuring concept, the complexity of expressing and translating these requirements would be prohibitive. CIMOSA addresses this issue at a high level by the recognition that the handling of such complexity can be aided by the separation of concerns, and by providing a mechanism to reconcile the inevitable conflicts arising between those different concerns. This has resulted in the definition of CIMOSA Views which allow to model and structure an enterprise according to four major aspects, thus:

-	Function View,

-	Information View,

-	Resource View

-	Organisation View

The four views are related along the Stepwise Generation Axis of the CIMOSA Architectural Framework. The Generation Process is a set of rules and guide-lines constraining the definition of one view and its relations to the other views (see D-series of items). The CIMOSA Views are applicable at all of the CIMOSA Modelling Levels. However, there is one integrated enterprise model at each Modelling Level of a Particular Architecture. CIMOSA Views do not define sub-models but provide a selection mechanism to cope with model complexity by focusing on specific model details and temporary ignoring others.

Figure B0-3000/1: An Example of a CIMOSA View

Important notice: The four CIMOSA Views (Function, Information, Resource and Organization) are the only four modelling views recognized so far by CIMOSA to model CIM systems. Other views could be defined in the future if required.

2.	Background Section

2.1	Examples

Figure B0-3000/1 highlights the Function View within the CIMOSA Architectural Framework.

2.2	Document References

1.	CEN/CENELEC 1990. Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling, ENV 40 003.

2.	CEN/TC310/WG1 1995. Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling. ENV 12 204.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Function View
CIMOSA Technical Baseline

Function View

B0-3100. Version: 4.3; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Documents one abstraction stand-point for the representation of enterprise operations in terms of their functionality, structure and behaviour by means of processes and activities of an enterprise.

1.2	Terms and Definitions

(1)	CIMOSA Function View:

(a)	describes the functional structure, the functionality, and behaviour (i.e. rules which define the process sequence or flow of action and control within an enterprise) as well as the inputs and outputs of the underlying functions required to satisfy the requirements (i.e. objectives and constraints or manufacturing strategies) of an Enterprise (see B1-1000 CIMOSA Function View, Modelling Paradigm Requirements and B1-2000 CIMOSA Function View Modelling Paradigms).

(b)	exists at, and defines constructs for use in all CIMOSA Genericity Levels.

(c)	exists at, and defines constructs for use in all CIMOSA Modelling Levels.

(2)	Process: dynamic behaviour of a set of functions capable to produce an enterprise result

(3)	Function: entity able to perform a state transformation (input into output) according to control information and supplied resources.

1.3	Abbreviations and Acronyms

CEN/CENELEC: 	Comité Européen de Normalisation/-"- Electro-technique

ENV:	European pre-Norm

1.4	Description

The primary operational task of an enterprise is to perform all those functions necessary to achieve its objectives. CIMOSA, via the Function View, provides an effective means of expressing those functions and their interdependencies in a consistent manner, together with a means for combining those functions in an orderly and flexible manner in order to realise given behaviours. It is a principle of the Function View to separate the concerns of structure, functionality and behaviour. Functions are considered to be reusable (unless otherwise prohibited) and are placed into a common pool. The Function View defines constructs, as presented in the Function View Modelling Paradigms item, for combining these functions in arbitrary ways, according to need, in order to realise higher level tasks whose behaviour is dictated by the particular structure thus imposed.

At the Particular Level, the Function View is a hierarchically structured description of the functions, their behaviour (dynamic aspect) and the functional structure (static aspect) of the enterprise, based on the objectives of the enterprise, reflecting external constraints and relevant inputs and outputs (ENV 40 003, ENV 12 204). The Function View defines constructs for use at all the CIMOSA Modelling Levels.

1.4.1	General Constraints

-	The use and application of the Function View constructs is constrained across the three Genericity Levels according to the Instantiation Process.

2.	Background Section

2.1	Examples (not Applicable)

2.2	Document References

1.	ENV 40 003. Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling. CEN/CENELEC, ENV 40 003. 1990.

2.	CEN/TC310/WG1 1995. Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling. ENV 12 204.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Information View
CIMOSA Technical Baseline

Information View

B0-3200. Version: 5.2; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Documents one abstraction stand-point for the representation of all business information (including that about physical materials and products) required by the various functions of the enterprise.

1.2	Terms and Definitions

(1)	CIMOSA Information View:

(a)	describes the information and information structure required by and in support of the functions defined in the Function View (see B2-1000 CIMOSA Information View, Modelling Paradigm Requirements  and B2-2000 CIMOSA Information View Modelling Paradigms).

(b)	exists at, and defines constructs for use in all CIMOSA Genericity Levels.

(c)	exists at, and defines constructs for use in all CIMOSA Modelling Levels.

(2)	Data: made up of two things: a fact (i.e. a value) and a meaning.

(3)	Information: the meaningful interpretation and correlation of some aggregation of data in order to allow one to make decisions or to communicate.

1.3	Abbreviations and Acronyms

CEN/CENELEC:	Comité Européen de Normalisation/-"- Electro-technique

ENV:	European pre-Norm

1.4	Description

The functions of an enterprise as defined in the Function View operate on defined information inputs and outputs. In order to consistently define, formalise, structure and present these inputs and outputs, CIMOSA has defined a set of constructs, as presented in the Information View Modelling Paradigms item, which are collected into the Information View. The relationships between the Information View constructs and the other View constructs is governed by the Generation Process. The Information View provides rules and guide-lines (through the Derivation Process) for the structuring of information thus established into a form applicable for implementing on data processing systems and for presentation to and manipulation by users. At the Particular Level, the Information View is a structured set of information objects, which were identified in the Function View and are not encompassed in other Modelling Views (ENV 40 003, ENV 12 204). The Information View defines constructs for use at all the CIMOSA Modelling Levels.

The Information View of an Enterprise is a set of specification, descriptive and implementation models and statements concerning all the short term and long term pieces of data and knowledge produced/stored/maintained/processed for the needs of enterprise users and applications. AMICE has chosen an Object-Entity-Relationship-Attribute approach for the Information View, which extends the traditional entity-relationship approach with object orientation at the user level. It is based on three modelling approaches, one for each CIMOSA Modelling Level:

-	the use of a semantic object-oriented model at the Requirements Definition Modelling Level

-	the use of a semantic data model (described in terms of the Entity-Relationship-Attribute Methodology) to define the Conceptual Schema and a set of External Schemata at the Design Specification Modelling Level

-	the use of classical data models for the Internal Schema and its related Implemented External Schemata at the Implementation Description Modelling Level

1.4.1	General Constraints

-	The use and application of the Information View constructs is controlled across the three Genericity Levels according to the Instantiation Process.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990. Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling, ENV 40 003.

2.	CEN/TC310/WG1 1995. Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling. ENV 12 204.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Resource View
CIMOSA Technical Baseline

Resource View

B0-3300. Version: 5.2; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Documents one abstraction stand-point for modelling the resources - humans, machines, applications - of enterprises.

1.2	Terms and Definitions

(1)	CIMOSA Resource View:

(a)	describes the required capabilities, the resources and their structure and location and the capabilities provided by those resources of the enterprise which perform the functions defined in the Function View (see B3-2000 CIMOSA Resource View, Modelling Paradigm Requirements and B3-2000 CIMOSA Resource View Modelling Paradigms).

(b)	exists at, and defines constructs for use in all CIMOSA Genericity Levels.

(c)	exists at, and defines constructs for use in all CIMOSA Modelling Levels.

(2)	Resource: any object of the enterprise which needs to be used in support to the execution of a function of the enterprise defined in the Function View.

1.3	Abbreviations and Acronyms

CEN/CENELEC:	Comité Européen de Normalisation/-"- Electro-technique

ENV:	European pre-Norm

1.4	Description

The Resource View contains relevant information on enterprise Resources for resource management purpose. Resources are enterprise entities which provide full or partial support for the execution of enterprise operations. In order to consistently define, formalise, structure and present these Resources, CIMOSA has defined a set of constructs which are visible in the Resource View. The relationships between the Resource View constructs and the other View constructs is governed by the Generation Process. The Resource View constructs, the interrelationships of these constructs, and their relations with other CIMOSA Views are defined in the Resource View Modelling Paradigm. At the Particular Level, the Resource View is a description of the resource organisation of the enterprise, that is the set of resources required to execute enterprise operations and their relations (ENV 40 003, ENV 12 204).

CIMOSA distinguishes among two exclusive subsets of Resources: active resources (or Functional Entities) which have some degree of intelligence or autonomy (they have a controller), and passive resources (Resource Components) which have no degree of intelligence or autonomy (they are always used by an active resource).

Examples of active resources are software applications, numerically controlled machines, robots, computer-controlled pieces of equipment, etc. Examples of passive resources are tools, carts, hand-driven machines, trucks, etc. The Resource View defines constructs for use at all the CIMOSA Modelling Levels. The Resource View of the Implementation Description Model is used in the Enterprise Operation Environment to support the allocation, acquisition and assignment of Resources which are needed to perform a particular function of the enterprise.

1.4.1	General Constraints

-	The use and application of the Resource View constructs is controlled across the three Genericity Levels according to the Instantiation Process.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990. Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling, ENV 40 003.

2.	CEN/TC310/WG1 1995. Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling. ENV 12 204.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Organisation View
CIMOSA Technical Baseline

Organisation View

B0-3400. Version: 5.2; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Documents one abstraction stand-point for modelling all relevant information about the responsibilities and authorisation for processes activities, information objects and resources of enterprises.

1.2	Terms and Definitions

(1)	CIMOSA Organisation View:

(a)	describes an enterprise's organisational structure, responsible and authorised for processes, functions, control, information and resources as defined in the Function View, Information View, and Resource View (see B4-1000 CIMOSA Organisation View, Modelling Paradigm Requirements and B4-2000 CIMOSA Organisation View Modelling Paradigms).

(b)	exists at, and defines constructs for use in all CIMOSA Genericity Levels.

(c)	exists at, and defines constructs for use in all CIMOSA Modelling Levels.

(2)	Responsibility: identification of the organisation unit assigned to take operational actions.

(3)	Authorization: identification of the organisation unit permitted to take engineering actions.

1.3	Abbreviations and Acronyms

CEN/CENELEC:	Comité Européen de Normalisation/-"- Electro-technique

ENV:	European pre-Norm

1.4	Description

The definition and identification of responsibilities and authority within an enterprise is an important consideration. An installed CIM system will not always function as desired (due to, for example, exception conditions, or changes in requirements), and therefore will need to make decisions (either through human intervention/decision-making, or by itself, or by a combination of the two) on how to adjust operations. Such decisions require a human and/or system component to assume responsibility for the actions: the Organisation View defines constructs for expressing these responsibilities and authority and setting them in an organisational structure. The Organisation View provides (through the Derivation Process) for the structuring of responsibilities and authority thus identified into a form applicable for instance for controlling system exception handling and supervision of human decision making processes.

At the Particular Level, the Organisation View is a description of the organisational structure of the enterprise and the responsibilities and authority of the individuals and organisational units within the enterprise (ENV 40 003, ENV 12 204). The Organisation View defines constructs for use at all the CIMOSA Modelling Levels.

1.4.1	General Constraints

-	The use and application of the Organisation View constructs is controlled across the three Genericity Levels according to the Instantiation Process.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990. Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling, ENV 40 003.

2.	CEN/TC310/WG1 1995. Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling. ENV 12 204.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


CIMOSA Modelling Levels
CIMOSA Technical Baseline

CIMOSA Modelling Levels

B0-4000. Version: 5.3; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Describes the modelling stages of the CIMOSA Architectural Framework defining three types of models, namely for Requirements Definition, Design Specification and Implementation Description.

1.2	Terms and Definitions

(1)	Modelling Level:

(a)	Level of abstraction corresponding to the main life cycle phases of enterprise model development.

(b)	It contains Generic Building Blocks and Building Block Types at the Generic Level and models at the Partial and Particular Levels.

(2)	CIMOSA Modelling Levels:

(a)	CIMOSA Architectural Framework defines, along its Stepwise Derivation Axis, three Modelling Levels:

-	the Requirements Definition Modelling Level;

-	the Design Specification Modelling Level; and

-	the Implementation Description Modelling Level.

(b)	Associated with each Modelling Level there exists:

-	a defined set of Generic Building Blocks and Building Block Types;

-	Partial Models; and

-	a Particular Model.

(3)	Life Cycle: definition of the model and system life cycle phases (Requirements Definition Model, Design Specification Model, Implementation Description Model)

1.3	Abbreviations and Acronyms (none)

1.4	Description

The process of developing a model of a CIM system does not happen in a single step. At each stage of the development process (e.g., define objectives, specify business requirements, design system, implement system) different levels of definition and expression are involved.

CIMOSA supports this process by identifying the major stages and decision points which are reached, associating Modelling Levels with each stage, and enabling the creation of suitable models at each level to fully express the results obtained. In particular, CIMOSA minimises the extent to which implementation concerns are included at business requirements specification stage. Each modelling Level contains an internal structure consisting of three levels of genericity and can be accessed via four Views. However, for a particular enterprise there is one integrated model at each Modelling Level which can be seen (i.e. accessed) from four different viewpoints.

It should be made clear that each Modelling Level forms part of a coherent whole and uses the appropriate modelling language (or paradigm). Furthermore the Partial Level contains sets of partially instantiated models spanning all Modelling Levels with each set of partially instantiated models being linked by the Derivation Process. Similarly the Particular Level contains several versions of one enterprise's Particular Model which spans all Modelling Levels and all Views in a coherent manner. The modelling levels which exist in CIMOSA and the associated models for each level all related along the Stepwise Derivation Axis are given here:

Modelling Level	Models
Requirements Definition Modelling Level	Partial and Particular Requirements Definition Models
Design Specification Modelling Level	Partial and Particular Design Specification Models
Implementation Description Modelling Level	Partial and Particular Implementation Description Models
The Stepwise Derivation Process provides an orderly derivation of enterprise implementation from enterprise requirements. This process employs design specifications to restructure the requirements from the user definition into more system related specification. Derivation is a process to derive the technological and system component choices from the user requirements. Thereby a translation process from a business description language into a system description language also takes place. Derivation itself is controlled by a set of guide-lines which defines steps in the process, constrains the process and ensures it is applied in a consistent manner. (This is further described in Model Creation Processes and System Life Cycle - See the D0-series of items).

Figure B0-4000/1: An Example of a CIMOSA Modelling Level

2.	Background Section

2.1	Examples

Figure B0-4000/1 highlights the Implementation Description Modelling Level within the CIMOSA Architectural Framework.

2.2	Document References

1.	CEN/CENELEC 1990. Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling, ENV 40 003.

2.	CEN/TC310/WG1 1995. Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling. ENV 12 204.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Requirements Definition Modelling Level
CIMOSA Technical Baseline

Requirements Definition Modelling Level

B0-4100. Version: 5.3; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Is used to express partial or particular enterprise requirements of what has to be done in the enterprise from the users point of view.

1.2	Terms and Definitions

(1)	Requirements Definition Modelling Level:

(a)	defines what has to be done in a business sense and terminology, in terms of enterprise activities and without reference to implementation options or decisions .

(b)	defines constructs applicable for use at each of the CIMOSA Generic, Partial and Particular Levels (Requirements Definition Model, Partial Requirements Definition Models, Particular Requirements Definition Model).

1.3	Abbreviations and Acronyms

RDM: Requirements Definition Model

PRDM: Particular Requirements Definition Model

1.4	Description

The Requirements Definition Modelling Level identifies the business requirements of the enterprise, reflecting the requirements phase of the enterprise modelling process. The requirements identified lead to the definition of enterprise operations, which can be further decomposed using constructs provided by the Generic Level. This still leaves options for the implementation to be chosen at both the Design Specification Modelling Level and the Implementation Description Modelling Level. The level of details of this modelling level is left to the users, but should be guided by the level of operational control desired. The Requirements Definition Model must state the required basic functionalities and capabilities as well as objects handled. In general, the Requirements Definition Model:

-	must not necessarily be complete

-	must not necessarily be consistent (*)

-	must be processable on a tool for on-line limited consistency checking

-	is entirely described by end-users

Requirements Definition Models reside at the Requirements Definition Modelling Level and use constructs particularly oriented towards expressing the business requirements of a CIM enterprise. The constructs are used to describe "what" has to be done and "how" things are to be done in a language which is:

(1)	easily understandable by business users;

(2)	translatable (via the Derivation Process), through Design Specification Models, into an Implementation Description Model; and

(3)	highly independent of the actual implementation details.

The Requirements Definition Modelling Level must support:

-	coarse requirements definition (i.e. mostly definition of Domains and Domain Relationships) as well as

-	detailed requirements definition (i.e. all Domains are fully detailed using all constructs provided by CIMOSA for this modelling level)

At the Generic Level, the Requirements Definition Modelling Level defines a reference catalogue of Generic Building Blocks and Building Block Types for expressing business requirements according to the four CIMOSA Views which can be used, via the Instantiation Process to generate Requirements Definition Models at the Partial and Particular Levels.

At the Partial Level, the Requirements Definition Modelling Level defines sets of partially-instantiated constructs or Partial Models which express typical business requirements of enterprises belonging to particular industry segments. These can be further instantiated to generate Requirements Definition Models at the Particular Level.

At the Particular Level, the Requirements Definition Modelling Level contains a Requirements Definition Model, which is composed of fully instantiated, structured constructs defining the business requirements of a particular enterprise.

A Particular Requirements Definition Model (PRDM) contains whatever the business users think is necessary to describe their business requirements using CIMOSA constructs. A PRDM can be revised along the Derivation Process to comply with design constraints and implementation issues (process iterations).

1.4.1	General Constraints

-	The instantiation of constructs and structures used within the Requirements Definition Modelling Level is governed by the Instantiation Process (see D-series of items).

2.	Background Section

2.1	Examples (tbd)

2.2	Document References

1.	CEN/CENELEC 1990. Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling, ENV 40 003.

2.	CEN/TC310/WG1 1995. Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling. ENV 12 204.

2.3	Open Issues (none)

(*)	After collection of all business requirements by different users it may happen that the whole model is not consistent. These inconsistencies will be resolved at the Design Specification Modelling Level and the RDM will thereby become consistent as well.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Design Specification Modelling Level
CIMOSA Technical Baseline

Design Specification Modelling Level

B0-4200. Version: 5.3; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Is used to specify partial or particular solutions to business requirements of CIM enterprises.

1.2	Terms and Definitions

(1)	Design Specification Modelling Level:

(a)	specifies how the enterprise operations are to be performed, that is the actions and processes that are to be performed to achieve the enterprise requirements taking time into account.

(b)	defines constructs applicable for use at each of the CIMOSA Generic, Partial and Particular Levels (Design Specification Model, Partial Design Specification Model,Particular Design Specification Model).

1.3	Abbreviations and Acronyms

DSM: 	Design Specification Model

PDSM: 	Particular Design Specification Model

1.4	Description

The role of the Design Specification Modelling Level is to restructure, detail and optimise user requirements in a consistent model, taking into account all business and technical constraints, and to specify a solution for those requirements. This optimisation is carried out by system designers who optimise the different user requirements from a global enterprise stand-point in terms of business needs and system capabilities. Note however that several models can be derived, tested and compared at this level and that the "best" one is selected for implementation. This model must deal with time and occurrences as well as function, information and resource behaviour to deal with system states. The resulting Design Specification Model has to be complete, consistent and unambiguous:

-	must be complete (all mandatory properties have been specified)

-	must be consistent (there does not exist two specifications in the model which contradict each other)

-	must be unambiguous (cannot be interpreted in more than one way)

-	must be transferable into code

-	must be executable for simulation purposes, i.e. it must provide a time horizon

-	is detailed, logically restructured and ultimately optimised in co-operation between end-users and system analysts.

The Design Specification Models are expressed in a form which is derived entirely from the Requirements Definition Model so that they can explicitly reflect the underlying business requirements of a particular enterprise through the intermediate stages of the System Life Cycle. The total set of Design Specification Models must collectively contain all the characteristics of the Requirements Definition Model, so that they make possible the derivation of complete Implementation Description Models.

At the Generic Level, the Design Specification Modelling Level defines a reference catalogue of Generic Building Blocks and Building Block Types for expressing partially-derived implementation description requirements according to the four CIMOSA Views which can be used, via the Instantiation Process to generate Design Specification Models at the Partial and Particular Levels.

At the Partial Level, the Design Specification Modelling Level defines sets of partially-instantiated constructs or Partial Models according to the four Views which express typical, partially-derived, implementation requirements of enterprises belonging to particular industry segments. These can be further instantiated to generate Design Specification Models at the Particular Level.

At the Particular Level, the Design Specification Modelling Level contains a Design Specification Model, which is composed of fully instantiated, structured, constructs defining the partially-derived implementation requirements of a particular enterprise. Several alternate Particular Design Specification Models (PDSM) can be considered during System Design. Only one will be considered for implementation.

1.4.1	General Constraints

-	The instantiation of constructs and structures used within the Design Specification Modelling Level is governed by the Instantiation Process (see D-series of items).

2.	Background Section

2.1	Examples (tbd)

2.2	Document References

1.	CEN/CENELEC 1990. Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling, ENV 40 003.

2.	CEN/TC310/WG1 1995. Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling. ENV 12 204.

2.3	Open Issues

1.	The use of formal techniques and formal languages to support computer processing of Design Specification Models is under investigation. The use of Petri nets to analyse model behaviour and predict system performance is also being investigated.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Implementation Description Modelling Level
CIMOSA Technical Baseline

Implementation Description Modelling Level

B0-4300. Version: 5.3; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Provides a complete system description of all implemented components of a CIM system.

1.2	Terms and Definitions

(1)	Implementation Description Modelling Level

(a)	describes the means and/or rules to be used in executing the enterprise operations as described at the Requirements Definition Modelling Level).

(b)	defines constructs applicable for use at each of the CIMOSA Generic, Partial and Particular Levels (Implementation Description Model, Partial Implementation Description Model, Particular Implementation Description Model).

1.3	Abbreviations and Acronyms

CIM:	Computer Integrated Manufacturing

IDM:	Implementation Description Model

PIDM: 	Particular Implementation Description Modelling Level

1.4	Description

The Implementation Description Modelling Level defines the means of execution of the enterprise model by selecting the real Information Technology and Manufacturing Technology resources. Resources such as humans, machines and application programs to be used as an integrated and effective set of components to execute the enterprise operations as described at the Requirements Definition and Design Specification Modelling Levels. It reflects the implementation phase of the enterprise model, which meets the requirements of the enterprise and takes into account non-determinism of real-world systems, i.e. can face exception handling situations.

The Implementation Description Model is created from the set of Design Specification Models by making product and technical choices regarding how the resources are to be provided, how and where data are to be stored and where and how the functionalities will be performed by choosing standard CIMOSA compliant products (from the component catalogue) which meet or exceed the specifications for the required functionalities and resources. This model is then given to implementors for CIM system implementation, and used to verify the implementation. Finally it is released for operation.

The Implementation Description Model has to be complete, consistent, unambiguous and transferable into code:

-	must be complete (all mandatory properties of constructs have been specified)

-	must be consistent (there does not exist two specifications in the model which contradict each other)

-	must be unambiguous (it cannot be interpreted in more than one way)

-	must be translatable into a computer executable form (either interpreted or compiled) for computer-controlled execution of processes of the model

The Implementation Description Models reside at the Implementation Description Modelling Level and use constructs which are particularly oriented to expressing the implementation requirements for a CIM system.

The implementation requirements are expressed in a form which is:

(1)	derived entirely from the Requirements Definition Model (through the Design Specification Models) so that it can explicitly reflect the underlying business requirements and design philosophy of a particular enterprise; and

(2)	directly processable via an integrated set of system components (of the data processing environment) installed for effective realisation of the enterprise business and operational requirements.

Given these characteristics, there will be a reasonable chance that the system components required for a given enterprise will already exist in the market place, and that for any which do not there will exist a CIMOSA specification from which they can easily be implemented.

At the Generic Level, the Implementation Description Modelling Level defines a reference catalogue of Generic Building Blocks and Building Block Types for expressing implementation requirements according to the four CIMOSA Views which can be used, via the Instantiation Process to generate Implementation Description Models at the Partial and Particular Levels.

At the Partial Level, the Implementation Description Modelling Level defines sets of partially-instantiated constructs or Partial Models according to the four Views which express typical implementation requirements of enterprises belonging to particular industry segments. These can be further instantiated to generate Implementation Description Models at the Particular Level.

At the Particular Level, the Implementation Description Modelling Level contains an Implementation Description Model, which is composed of fully instantiated, structured, constructs defining the implementation requirements of a particular enterprise.

1.4.1	General Constraints

-	The instantiation of constructs and structures used within the Implementation Description Modelling Level is governed by the Instantiation Process (see D-series of items).

2.	Background Section

2.1	Examples (tbd)

2.2	Document References

1.	CEN/CENELEC 1990. Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling, ENV 40 003.

2.	CEN/TC310/WG1 1995. Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling. ENV 12 204.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


CIMOSA Genericity Levels
CIMOSA Technical Baseline

CIMOSA Genericity Levels

B0-5000. Version: 5.2; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Describes the particularisation principle of the CIMOSA Architectural Framework defining three levels, namely the Generic Level, the Partial Level and the Particular Level.

1.2	Terms and Definitions

(1)	Genericity Levels: define different levels of genericity for different levels of abstraction from real world objects.

(2)	Genericity Levels of the  CIMOSA Architectural Framework:

(a)	define, along its Stepwise Instantiation Axis, three Genericity Levels:

-	the Generic Level;

-	the Partial Level; and

-	the Particular Level.

(b)	Generic and Partial Level collectively constitute the set of models in the CIMOSA Reference Architecture.

(c)	The Particular Level constitutes the set of models in a CIMOSA Particular Architecture.

1.3	Abbreviations and Acronyms (none)

1.4	Description

CIMOSA is intended to provide a framework for the specification, design and implementation of CIM systems providing a high degree of flexibility. Therefore CIM systems should as far as possible be constructed from standard components. For this to be achieved, there needs to be an underlying commonality of definition and expression from which all particular realisations are derived. This leads to the notion of genericity. In adopting this principle, CIMOSA has recognised the need for different levels of genericity, and has defined three such levels, ranging from the highly generic to the highly particular, and therefore called Generic Level, Partial Level and Particular Level.

The purpose of this genericity principle is to enforce the use of common languages (defined in terms of Generic Building Blocks and Building Block Types) from which all constructs are instantiated, enforce the use of standard components in the model and enforce re-use of existing Partial Models in order to reduce Particular Model development cycle times. The three Genericity Levels are related along the Stepwise Instantiation Axis.

Figure B0-5000/1: An Example of a CIMOSA Genericity Level

The Stepwise Instantiation Process permits the orderly movement from a more generic level to a more particular level. A number of steps performed in the correct order permit movement from generic, abstract constructs to completely determined particular systems. The CIMOSA Genericity Levels are applied across all of the CIMOSA Views and all of the CIMOSA Modelling Levels.

2.	Background Section

2.1	Examples

Figure B0-5000/1 highlights the Generic Level within the CIMOSA Architectural Framework.

2.2	Document References

1.	CEN/CENELEC 1990. Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling, ENV 40 003.

2.	CEN/TC310/WG1 1995. Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling. ENV 12 204.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Generic Level
CIMOSA Technical Baseline

Generic Level

B0-5100. Version: 4.3; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Provides a reference catalogue of Generic Building Blocks and Building Block Types for all modelling views and levels of the CIMOSA Architectural Framework.

1.2	Terms and Definitions

(1)	Generic Level of the CIMOSA Architectural Framework:

(a)	is a subdivision of the CIMOSA Reference Architecture.

(b)	defines the full reference set of CIMOSA Generic Building Blocks and Building Block Types, and the rules and constraints for their use in creating models at the Partial Level and Particular Level via the CIMOSA Model Creation Processes.

(2)	Generic Building Block: a generalisation (abstraction) of all Building Blocks (Types, Partial, Particular) instantiated from it. It contains a minimum set of attributes common to all Building Blocks (Types, Partial, Particular) instantiated from it.

(3)	Building Block Type: a specialisation of a Generic Building Block or a more generic Building Block Type.

(4)	Building Block Component: Presently the term component is used as defined in the Oxford Dictionary of Current English being a constituent of a larger entity.

1.3	Abbreviations and Acronyms (none)

1.4	Description

The Generic Level of CIMOSA is the definitive reference base of all Generic Building Blocks and Building Block Types of CIMOSA and the rules/constraints governing their application (via the CIMOSA Model Creation Processes). The building blocks and their related rules/constraints are maintained in a structured catalogue, according to the four CIMOSA Views) and the three CIMOSA Modelling Levels. Within each CIMOSA View and Modelling Level the Generic Building Blocks are categorised into different Building Block Types, but otherwise no structuring exists at the Generic Level. This structuring (into models at the Partial and/or Particular Levels) is achieved through the application of the Instantiation Process.

Generic Building Block is the collective term for all generic modelling language constructs which are provided by AMICE. The Generic Building Blocks are the most generic Building Blocks provided to the "enterprise modeller". The Generic Building Blocks form a closed set. Additions and changes can only be made by an "authorised institution" (e.g. standardisation bodies or AMICE). So far, the AMICE Consortium is the only responsible entity authorised to carry out those additions or changes.

Building Block Types are the specialisations of Generic Building Blocks or of a more generic Building Block Type. Building Block Types are organised in a hierarchical structure, a Generic Building Block is always the top of the type hierarchy. Building Block Types can be viewed as a reference catalogue from which the user (enterprise modeller) may select the most appropriate modelling construct to describe the partial or particular model. The Building Block Types are a closed set. Additions and changes can only be made by an "authorised institution" e.g. standardisation bodies or AMICE. The object orientation of the CIMOSA Generic Level has been addressed in item B0-2100 (CIMOSA Reference Architecture).

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990. Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling, ENV 40 003.

2.	CEN/TC310/WG1 1995. Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling. ENV 12 204.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Partial Level
CIMOSA Technical Baseline

Partial Level

B0-5200. Version: 4.2; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Defines the part of the CIMOSA Architectural Framework which contains structured sets of partially instantiated building blocks to create partially reusable models according to the enterprise size or industry sector.

1.2	Terms and Definitions

(1)	Partial Level of the CIMOSA Architectural Framework:

(a)	a subdivision of the CIMOSA Reference Architecture.

(b)	defines a reference catalogue of partially-instantiated models, and the rules and constraints for their use in creating models at the Particular Level via the CIMOSA Model Creation Processes.

(2)	Partial Models at the Partial Level: represent similar characteristics for common parts of manufacturing enterprises, very often belonging to a given industry segment.

(3)	Partial Model defined by means of:

(a)	a set of partially instantiated Generic Building Blocks or Building Block Types, which are related to each other;

(b)	configuration rules, which define which combination of constructs a Partial Model is allowed to contain; and

(c)	consistency rules, which define which relationships are allowed in a consistent model.

1.3	Abbreviations and Acronyms

1.4	Description

CIMOSA recognises that, while each individual enterprise has its own unique CIM requirements, many of them will still exhibit characteristics, structures, manufacturing strategies, etc., in common with each other. This commonality may exist between enterprises within a given industry sector (such as aerospace, automotive, electronics), of a given company size, of a given nationality, or other criteria. If the creation of models at the Particular Level was always to be made directly from the Generic Level, much of this commonality would go unrecognised and significant cost reduction/time savings would fail to be capitalised on. In response to this observation, CIMOSA has defined the Partial Level. It greatly improves the economy of the CIM system design process by providing "partially-instantiated" constructs (termed Partial Models) which apply to a constrained set of enterprises and which capture the functional, information, resource and organisational commonality within that set. Models at the Partial Level therefore contain a degree of structuring (which is not the case at the Generic Level) into 'macro' constructs generated from the atomic building blocks at the Generic Level. The Partial Models and their related rules/constraints are maintained in a structured catalogue, according to the four CIMOSA Views and the three CIMOSA Modelling Levels.

Models at the Partial Level may be independent of each other, but may also be defined in a hierarchical manner. Also Partial Models can be built from other Partial Models. Since requirements for models at the Partial Level will grow over time, the Partial Level is considered to be an open set. This set will be populated according to the needs of standards bodies, industry offerings and even internal enterprise activities. Models at the Partial Level are the prime means by which CIMOSA encapsulates industry requirements, and provide a more realistic and usable tool for instantiating CIMOSA for a given enterprise.

1.4.1	General Constraints

-	Each model at the Partial Level must consist of constructs, structures, rules and constraints instantiated from the Generic Level.

-	The extension and maintenance of the Partial Level is ruled and constrained by an "authorised institution" e.g. standardisation bodies or AMICE.

2.	Background Section

2.1	Examples

Figure B0-5200/1 illustrates an example of the kinds of model which may exist at the Partial Level. A hierarchical set of models is shown for suppliers to the automotive manufacturing industry, further subdivided according to enterprise size and type of business. Through instantiation an enterprise particular model may be created from any of the partial models at the partial level and/or from the CIMOSA generic constructs at the generic level.

Figure B0-5200/1: Example Models at the Partial Level

2.2	Document References

1.	CEN/CENELEC 1990. Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling, ENV 40 003.

2.	CEN/TC310/WG1 1995. Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling. ENV 12 204.

2.3	Open Issues

1.	The criteria for identifying models at the Partial Level are as yet undefined.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Particular Level
CIMOSA Technical Baseline

Particular Level

B0-5300. Version: 5.2; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Defines the part of the CIMOSA Architectural Framework which contains a model representation of one particular enterprise. It can be instantiated either form the Generic Level or directly from the Partial Level.

1.2	Terms and Definitions

(1)	Particular Level of the CIMOSA Architectural Framework:

(a)	contains the models of the CIMOSA Particular Architecture.

(b)	defines the fully-instantiated models of a CIM enterprise created either form the Generic or Partial Levels via the CIMOSA Model Creation Processes.

(2)	Particular Models at the Particular Level: represent specific characteristics of a particular manufacturing enterprise by means of sets of fully instantiated Generic Building Blocks, Building Block Types and/or Partial Models (Building Block Instances).

1.3	Abbreviations and Acronyms

1.4	Description

The Particular Level of CIMOSA is entirely dedicated to a given enterprise. For such an enterprise a CIM system implementation is to be ultimately described by particular models which embody all necessary knowledge of the enterprise in a form which can be used directly for the specification of an integrated set of manufacturing technology and information technology components necessary for effective realisation of the enterprise operations.

For a given enterprise Particular Models consist of a Requirements Definition Model, one or more Design Specification Models derived from the previous one, and one Implementation Description Model derived from the Design Specification Model selected for implementation. Each of these models may exist with several versions. But all of these models belong to an integrated whole since they are related to one another via the CIMOSA Derivation Process.

The Particular Level can be instantiated either directly from the Generic Level and/or from the Partial Level.

1.4.1	General Constraints

-	Each model at the Particular Level must consist of constructs and structures directly instantiated from the Generic Level and/or Partial Level.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990. Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling, ENV 40 003.

2.	CEN/TC310/WG1 1995. Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling. ENV 12 204.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


CIMOSA Modelling Object
CIMOSA Technical Baseline

CIMOSA Modelling Object

B0-7000. Version: 1.8; Last Update: 94.06.22

1.	Technical Section

1.1	Purpose and Scope

Describes the structuring principles of the Meta-model for CIMOSA constructs.

1.2	Terms and Definitions

(1)	CIMOSA Modelling Object (Root Object):

(a)	defines structuring concepts of the CIMOSA model. They are structured according to the object-oriented approach.

(b)	are used to structure models according to the CIMOSA Modelling Framework. They cover: Generic Building Blocks, Building Block Types, Building Block Instances and Building Block Occurrences.

1.3	Abbreviations and Acronyms (none)

1.4	Description

The Instantiation Process allows to generate Particular Models (populated with Instances and possibly with some of their Occurrences) from the CIMOSA Reference Architecture (itself populated with Generic Building Blocks, Building Block Types and partial Instances).

A Type proceeds through an Instantiation Process to form a particular Instance. From there, many Occurrences are created at run-time and appear to the external world as Embodiments.

CIMOSA Modelling Objects are defined on the basis of the object-oriented approach [1].

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	J. Rumbaugh et al. Object-Oriented Modelling and Design, Prentice-Hall, Englewood Cliffs, NJ, 1991.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Generic Building Block
CIMOSA Technical Baseline

Generic Building Block

B0-7100. Version: 1.0; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Defines the most generic concept for structuring CIMOSA constructs.

1.2	Terms and Definitions

(1)	Generic Building Block:

(a)	is a generalisation (abstraction) of all Building Blocks (Types, Partial, Particular) which can be instantiated from it. It contains a minimum set of elements common to all Building Blocks (Types, Instances, Occurrences) instantiated from it.

(b)	has the nature of an object class and therefore is defined by its name, a finite list of elements (either atomic properties defining descriptive characteristics or structured elements) and rules constraining the set of possible values for each element.

1.3	Abbreviations and Acronyms

CAEE: Computer-Aided Enterprise Engineering

1.4	Description

Generic Building Block is the most generic class of modelling entities defined in CIMOSA. Its parent class is the object class as defined in the object-oriented approach (Rumbaugh, 1991). The full set of Generic Building Blocks as defined at the Generic Level of the CIMOSA Reference Architecture form the basic primitives of the CIMOSA enterprise modelling language. This set is a closed set defined by AMICE or standardisation bodies.

Any CIMOSA Generic Building Block can be fully or partially instantiated to define Building Block Instances. Types and sub-types can be defined from a Generic Building Block as a hierarchy of Building Block Types, as in the object-oriented approach and using the property inheritance mechanism (Rumbaugh, 1991).

The syntax and semantics for describing each CIMOSA Generic Building Block are documented in a description template. Templates for all CIMOSA Generic Building Blocks are all defined at the Generic Level of the CIMOSA Reference Architecture.

All Generic Building Blocks are made of:

-	a header

-	a body containing:

-	a non-empty list of elements structured into Descriptional Properties and Behavioural Properties

-	a list of standard applicable methods

The header of all Generic Building Blocks at any Modelling Level is made of:

-	a type (name of parent Generic Building Block or Building Block Type)

-	an identifier (a constrained character string)

-	a name (character string)

-	a design authority (name of person or organisational entity having the authority to design/maintain the construct)

The header of all Generic Building Blocks at the Design Specification and Implementation Description Modelling Levels is inherited from the Generic Building Blocks at the Requirements Definition Modelling Level and is amended by:

-	an operation responsibility (identifier/name of organisational entity having responsibility on the construct in Enterprise Operation Environment)

-	an operation authority (identifier/name of an organisational entity having authority to take control on this construct in Enterprise Operation Environment)

where the contents of the type, identifier, name and design authority can also be inherited from the Requirements Definition Modelling Level. An organisational entity can be an Organisation Unit or an Organisation Cell (as defined in the Organisation View). The entry Type is left empty or can indicate "object" for Building Block Types meaning that there is no parent structure.

The list of elements are either:

-	simple entries with a name and a data type (text, integer, Boolean)

-	reference to other building blocks (entry name and list of identifiers/names of constructs)

-	a Building Block Component, i.e. a structured entry, the syntax of which is imposed by CIMOSA

The standard list of methods applicable to Generic Building Blocks for their management in the Enterprise Engineering Environment include:

-	creation of an instance of this type

-	deletion of an instance of this type

-	modification of an instance of this type

-	renaming an instance of this type

This structure and methods must be supported by Computer-Aided Enterprise Engineering tools implementing CIMOSA constructs (CIMOSA compliant tools).

2.	Background Section

2.1	Examples

Generic Building Blocks define the most generic types of a class of CIMOSA constructs. For instance, the Event class is defined by the following description template:

EVENT

Header Type Identifier: Name: Design Authority:	[relevant category - select from list] [EV-<unique identifier>] [name of the Event instance in the form: <adjective > <noun> <noun>: relates to the object causing the Event  <adjective>: qualifying attribute] [<identifier> / <name> of Orgnisation Unit with authority to design/maintain this particular instance]
Body A. Descriptional Properties DESCRIPTION: RELATED OBJECT VIEW:  B. Relational Properties GENERATED BY: TRIGGERS:	[textual description of the instance; optional] ['NIL or <identifier> / <name> of the Object View instance containing the information content of occurrences of this Event instance] [list of <identifier> / <name> of instances of Domain, Enterprise Activity or Resource, occurrences of which can generate occurrences of this Event instance] [list of <identifier> / <name> of Domain Process instances, occurrences of which can be triggered by means of occurrences of this Event instance. Automatically maintained by the CAEE tool]
2.2	Document References

1.	CEN/CENELEC 1990. Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling, ENV 40 003.

2.	CEN/TC310/WG1 1995. Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling. ENV 12 204.

3.	J. Rumbaugh et al. Object-Oriented Modelling and Design, Prentice-Hall, Englewood Cliffs, NJ, 1991.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Building Block Type
CIMOSA Technical Baseline

Building Block Type

B0-7200. Version: 0.4; Last Update: 94.06.22

1.	Technical Section

1.1	Purpose and Scope

Defines an ontology of classified classes of CIMOSA constructs, helping the user to select the construct type s/he needs for his/her enterprise model development.

1.2	Terms and Definitions

(1)	Building Block Type:

(a)	is a specialisation of a Generic Building Block or a more generic Building Block Type.

(b)	has the nature of an object class and therefore is defined by its name, a reference to its parent class, a list of elements (properties defining descriptive characteristics or components) and rules constraining the set of possible values for each element.

1.3	Abbreviations and Acronyms (none)

1.4	Description

A Building Block Type is a sub-type of a Generic Building Block or of a more generic Building Block Type. As object classes, Building Block Types can be organised into hierarchies of types, called ontologies, where the root of the hierarchy is one of the CIMOSA Generic Building Blocks. The term "type" is used here in the sense of "class" as defined in the object-oriented approach (Rumbaugh, 1991). A more specialised Building Block Type in a type hierarchy inherits the structure of its parent Building Block Type.

The full set of Building Block Types defined and categorised at the Generic Level of the CIMOSA Reference Architecture form additional primitives for the CIMOSA enterprise modelling language. This set is a closed set defined by AMICE or standardisation bodies. Any CIMOSA Building Block Type can be fully or partially instantiated to define Building Block Instances. The syntax and semantics for describing CIMOSA Building Block Types are documented in a description template defined as a specialisation of the template of their respective Generic Building Block.

All Building Block Types inherit the structure of their parent Generic Building Block or Building Block Type, i.e. header, list of elements and methods. They can constrain the set of values of their elements (entries), add new elements or overwrite the definition of some elements. The entry Type of the header part cannot be left empty and must indicate the parent structure of the next upper level (i.e. the name of a Generic Building Block or the name of a more generic Building Block Type).

2.	Background Section

2.1	Examples

(a)	Building Block Types for manufacturing Enterprise Activities have been categorised into four major classes:

- Make activities	- Verify activities
- Move activities	- Rest activitiesThe

Make activity class can itself be sub-categorised into:

- Machining activities	- Cover activities
- Heat treatment activities	- Assembly activities
- Chemical treatment activities
(b)	Building Block Types define sub-classes of Generic Building Blocks. For instance, the Machine Breakdown Event class is defined by the following description template, as a restriction of the Event type (e.g. source must be a machine and no accompanying Object View):

MACHINE BREAKDOWN EVENT

Header  Type  Identifier: Name: Design Authority:	Machine Breakdown Event [EV-<unique identifier>] [name of the Event instance in the form: <adjective > <noun> <noun>: relates to the object causing the Event  <adjective>: qualifying attribute]  [<identifier> / <name> of Organisation Unit with authority to design/maintain this particular instance]
Body  A. Descriptional Properties DESCRIPTION: RELATED OBJECT VIEW:  B. Relational Properties GENERATED BY: TRIGGERS:	[textual description of the instance; optional]  NIL [list of <identifier> / <name> of a Resource instance, occurrences of which can generate occurrences of this Event instance]  [list of <identifier> / <name> of Domain Process instances, occurrences of which can be triggered by means of occurrences of this Event instance.]
2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Building Block Instance
CIMOSA Technical Baseline

Building Block Instance

B0-7300. Version: 2.5; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Defines a user-defined class of CIMOSA constructs belonging to one of the generic types and used for model creation in the Enterprise Engineering Environment.

1.2	Terms and Definitions

(1)	Building Block Instance (or simply Instance): is a user-defined individual of a Generic Building Blockor Building Block Type , the characteristics of which (i.e. elements) have been partially (Partial Level) or fully (Particular Level) defined.

1.3	Abbreviations and Acronyms (none)

1.4	Description

An Instance is a user-defined class of constructs defined from generic classes provided by the Generic Level of the CIMOSA Reference Architecture. CIMOSA calls the process of generating Instances from a Generic Building Block or a Building Block Type the Instantiation Process. This process does not have to be completed in one pass. CIMOSA allows the existence of intermediate steps (Partial Models) at which the Instance definition is only partly complete. The process ends up with a particular, fully defined Instance.

An Instance is a user-defined class of objects in object-oriented terminology. Building Block instances inherit the generic structure of Building Block Types (header, list of elements and methods).

The Computer-Aided Enterprise Engineering tools implementing CIMOSA constructs must also support management information for Building Block Instances such as (This information is not part of the construct itself but must be kept separately):

-	item author

-	creation date (date)

-	last revision (date)

-	version number

1.4.1	General Constraints

-	The Instance structure is constrained by its type (Generic Building Block or Building Block Type).

2.	Background Section

2.1	Examples

Given the template for generic type for Events an example of an Event instance may be:

EVENT

Header Type Identifier: Name: Design Authority:	Event/Management-Order  EV-01 'Order Management Request' OU-01: 'M. Synders', OC-004 'Accounting'
Body A. Descriptional Properties: DESCRIPTION: RELATED OBJECT VIEW:  B. Relational Properties: GENERATED BY: TRIGGERS:	This management order is issued by the Accounting Department and asks for starting customer order processing.  OV-002 'Manufacturing Order' OC-004 'Accounting' DP-01 'Order Management'
2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Building Block Occurrence
CIMOSA Technical Baseline

Building Block Occurrence

B0-7400. Version: 2.2; Last Update: 94.06.22

1.	Technical Section

1.1	Purpose and Scope

Is a run-time parameterised copy of a particular instance as required during execution within the Enterprise Operation Environment.

1.2	Terms and Definitions

(1)	Building Block Occurrence (or simply Occurrence): is a run-time copy of a particular Building Block Instance, as required during execution within the Enterprise Operation Environment.

1.3	Abbreviations and Acronyms (none)

1.4	Description

The concept of Building Block Occurrence needs to be differentiated from the concept of Building Block Instance, by being its run-time descriptive realisation, i.e. it is fully instantiated and it has a consistent set of run-time values. There are many reasons for having multiple copies (Occurrences) of an Instance such as: to improve the response time of a system, or to support concurrent (i.e. parallel) processing, etc. The concept of occurrence in CIMOSA is equivalent to the concept of occurrence of an object in the object-oriented approach.

1.4.1	General Constraints

-	The Building Block Occurrence is constrained by the Building Block Instance, and therefore by the Generic Building Block it represents.

2.	Background Section

2.1	Examples

The example presents an Occurrence "John S. Smith" of an Instance "Person" of an object.

Instance: Person	Occurrence: John S. Smith
- ID: integer - First_name: char(10) - Family_name: char(10) - Age: integer - Address: char(30)	- ID: 115  - First_name: "John S."- - Family_name: "Smith" - Age: 45 - Address: "1, Oxford Street, W1 London, UK"
2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


CIMOSA Models
CIMOSA Technical Baseline

CIMOSA Models

B5-1000. Version: 1.1; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Identifies vision, scope and development process of CIMOSA Models and refers to the life cycle concept underlying the CIMOSA enterprise modelling framework.

1.2	Terms and Definitions

(1)	Models: abstract representations of objects (physical or non-physical).

(2)	CIMOSA Models:

(a)	are used to describe the different phases of the enterprise life cycle (Requirements Definition Model, Design Specification Model andImplementation Description Model).

(b)	are subject to an enterprise engineering process (model development process) which is concerned with both model creation and model maintenance (model update and modification).

(c)	contain sets of instances of Generic Building Blocks and Building Block Types structured to present a solution to problem areas in manufacturing enterprises in a process oriented language.

(d)	may represent partial (partially instantiated) or particular (fully instantiated) solutions.

1.3	Abbreviations and Acronyms

RDM	Requirements Definition Model

DSM	Design Specification Model

IDM	Implementation Description Model

1.4	Description

CIMOSA models are sets of classified, partially or fully instantiated definitions of one or more building block instances. In other words they can be any kind of consistent aggregation of building block instances. These models can be retrieved and reused by individual companies in the creation of their Particular Model to take advantage of previous work, reduce workload and design time and contribute to standardisation of manufacturing activities.

Using a process oriented language CIMOSA allows to describe in enterprise functionality, to identify the required information and resources and to specify the relevant organisational aspects of the operation (responsibility and authorisation) as well. The latter are required for handling operational exceptions as well as to provide for a controlled model engineering process.

1.4.1	CIMOSA Vision on Enterprise Modelling

CIMOSA views an enterprise as a dynamic system made of Domains (i.e. sub-systems) containing interacting Domain Processes generating, consuming or simply using enterprise Events and objects (perceived as Object Views). Domain Processes are activated by Events (i.e. solicited or unsolicited real-world happenings). Thus CIMOSA is based on an event-driven, process-based, modelling paradigm. In order to limit the "universe of discourse" or scope of a particular model CIMOSA provides the user with the possibility to define Domains, i.e. consistent areas of business functionality which can then be easily integrated.

Figure B5-1000/1: Set of Domains and Domain Processes

Figure B5-1000/1 demonstrates the CIMOSA Vision on enterprise modelling. The Domain (DM-x) captures the particular objectives and constraints for this "universe of discourse". Its boundaries will be identified by sets of Domain Relationships. Global functionalities of the domains are identified as Domain Processes (DPx.y). The Events which trigger the Domain Processes and the objects (Results described by Object Views) crossing the Domain boundary to be manipulated inside the Domain are identified as well. This encapsulation of Domain Processes into Domains will also ensure coexistence of CIMOSA and non CIMOSA processes and will support graceful migration from existing situations to CIMOSA compliant solutions. Domains and Domain Processes are essential constructs of CIMOSA to define well-structured CIM environments.

Figure B5-1000/2: Decomposition of Domain Process into Network of Enterprise Activities

Domain Processes define the major functionalities and behaviour of the enterprise. These are stand-alone processes triggered by means of Events and governing the way Enterprise Activities (EAn) are executed according to so-called Procedural Rule Sets and Declarative Rules to produce an expected result (see Figure B5-1000/2). Procedural Rule Sets and Events represent the behaviour and Enterprise Activities the functionality of the Domain Process. Objectives and Constraints (Declarative Rules) represent business know-how (i.e. business procedures, policies or rules). Enterprise Activities use, process, create enterprise objects (physical objects or information entities) defined in the model as Object Views. To ease the structuring of the model CIMOSA also provides the concept of Business Process (BPx.y.z), which makes it possible to decompose a Domain Process into (re-usable) sub-processes (Business Processes). Thus a fully defined Domain Process equates to a network of Enterprise Activities linked by Procedural Rule Sets. This is an important feature of CIMOSA which provides one instantiated model of:

-	the flow of control (in the form of Behavioural Rules)

Object Views are specific aspects of objects (including resource objects) as they are perceived by the users and used by the functions of the enterprise. Objects are formally described as Enterprise Objects. Object Views can be made of Object Views (sub-views) and Enterprise Objects can be made of Enterprise Objects (sub-objects). Both contain Information Elements, which are elementary descriptive properties of objects. Information Elements are subject to Integrity Rules, which define constraints applicable to data (to verify their consistency or integrity).

Furthermore Enterprise Objects can be related to one another by means of (1) Object Abstraction Mechanisms (which define semantic links of objects) or (2) Object Relationships (which are user-defined links between objects). Finally configuration requirements can be defined on Enterprise Objects in terms of management of Versions (new occurrences) and Variants (new structures of objects).

Object Views can be used to represent physical (i.e. concrete) appearances of objects or abstract (i.e. information) description of objects. For instance, a physical part on a machine-tool is a Physical Object View while its description in the computer system is an Information Object View of the same Enterprise Object part. Object Views can be used in a CIMOSA model as Function Input, Control Input and Function Output of Enterprise Activities (and therefore of their employing Domain/Business Processes). Thus a major advantage of this feature is that CIMOSA can easily represent:

-	the flow of information in the form of data flow diagrams if only Information Object Views are considered

-	the flow of materials (e.g. parts, materials, etc.) if only Physical Object Views are considered in the same integrated model. This is specific to the Requirements Definition Modelling Level (at lower levels everything is information).

1.4.2	Scope of the Model

The scope of a particular model is left to the user. However since CIMOSA is concerned with CIM, it is intended to model the functionalities (and their flow of control) which need to be integrated and later be computer-controlled during their execution. CIMOSA imposes no constraints on the scope of a particular model within any enterprise: it may be used to model the whole enterprise, or only selected areas called Domains, as desired.

1.4.3	Level of Detail of the Model

The level of details in a particular model is left to the user as well. CIMOSA allows for coarse or for very detailed CIM system definition. Coarse definition means that only Domains are defined, their Domain Processes identified with related Events and only major Enterprise Activities and their associated Procedural Rule Sets may be defined. Very detailed definition means that for all Domains their Domain Relationships, all Domain Processes and their triggering Events have been defined as well as their internal structure in terms of Business Processes and Enterprise Activities, and Declarative Rules have been fully defined according to the operation control and monitoring needed.

1.4.4	Model Development Process

The particular model has a relationship with the outside world (via Events but also Object Views). It is a description of the enterprise system, its static functionality and its dynamic behaviour). The particular model is envisaged as being developed through four main stages which are derived from each other and for which CIMOSA provides applicable constructs:

1)	Definition of requirements resulting in the Requirements Definition Model (RDM)

2)	Specification of system design fulfilling the defined requirements resulting in the Design Specification Model (DSM). This model is derived from the previous model (RDM) through amendment and extension of the model contents

3)	Description of the system implementation recording design choices and deviations resulting in the Implementation Description Model (IDM). Again the previous model (DSM) is amended to record the final enterprise system to be used in operation.

4)	Formal release of the model following validation and verification provides the base for the ideal use of modelling: model driven enterprise operation control and monitoring.

This sequence of steps describes a top-down analysis and design approach (TO-BE analysis and design) for the particular model creation. It is suitable for defining a new manufacturing system. A bottom-up approach can also be applied for modelling of AS-IS environments (i.e. existing manufacturing systems) for evaluation of alternative designs. In this case analysis starts with the description of the current implementation from which alternative system designs are derived.

2.	Background Section

2.1	Examples (tbd)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Requirements Definition Model
CIMOSA Technical Baseline

Requirements Definition Model

B6-1000. Version: 1.1; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Contains the constructs at the Requirements Definition Modelling Level, used to instantiate Partial and Particular Models.

1.2	Terms and Definitions

(1)	Requirements Definition Model (RDM):

(a)	consistent instantiation of CIMOSA Generic Building BlocksGeneric_Building_Block and/or Building Block Types and/or Partial Models (Partial Requirements Definition Models) for requirements definition in order to express the business requirements of a particular Enterprise (Particular Requirements Definition Model).

(b)	contains all the business requirements of a CIM enterprise in terms of functionality, information, resource and organisation.

(c)	expresses the business requirements using the CIMOSA Function, Information, Resource and Organisation Views.

(d)	provides only business user type representation

1.3	Abbreviations and Acronyms

RDM	Requirements Definition Model

PRDM	Particular Requirements Definition Model

1.4	Description

An enterprise is described, via the Particular Requirements Definition Model (PRDM), in terms of

-	functions required to satisfy the objectives of the enterprise by taking into account its constraints,

-	control structures, i.e. the rules which define the desired sequence of activities within the enterprise and the principles underlying the processes of the enterprise.

-	information needed and produced in the course of the enterprise operation.

-	capabilities required to perform the activities

-	organisational aspect needed for the control of the model engineering process.

1.4.1	CIMOSA Requirements Definition Modelling

CIMOSA views an Enterprise as a dynamic system made of Domains (i.e. sub-systems) containing interacting Domain Processes generating, consuming or simply using enterprise Events and objects (perceived as Object Views).

The Particular Requirements Definition Model has a relationship with the outside world (via Events and Object Views). It is a description of the enterprise system requirements but is not concerned with the detailed mechanism of how such requirements are fulfilled (though the implementation of a Particular Requirements Definition Model may be constrained by Declarative Rules defined within that model).

The Particular Requirements Definition Model is envisaged as being developed in four main stages, for which CIMOSA provides applicable constructs:

(a)	Identification of the Domains by establishing their Domain Objectives and Domain Constraints, their boundary (i.e. set of Domain Relationships) and the major tasks to be performed via the instantiation of Domain Processes and their sources of activation or stimulus (Events);

(b)	Functional Decomposition of Domain Processes into Business Processes and Enterprise Activities, according to their position in the decomposition hierarchy. Identification of other Events, if any;

(c)	Behaviour Analysis (i.e. definition of Ending Statuses, triggering conditions and sets of Behavioural Rules); and

(d)	Functional Analysis (i.e. instantiation of Enterprise Activities and definition of their inputs and outputs).

CIMOSA provides a set of generic constructs which allow to model the business requirements of the enterprise operation or parts thereof. Figure B6-1000/1 shows these Generic Building Blocks and their relations between each other.

CIMOSA is based on an event-driven, process-based, modelling paradigm. In order to limit the "universe of discourse" or scope of a PRDM CIMOSA provides the user with the possibility to define Domains, i.e. consistent areas of functionality which can then be easily integrated.

The Domain captures the particular objectives and constraints for this "universe of discourse". Its boundaries will be identified (set of Domain Relationships) as well as its global functionalities (Domain Processes), the Events which trigger the Domain Processes and the objects (described as Object Views) crossing the Domain boundary and are manipulated inside the Domain by Enterprise Activities.

Domain Processes define the major functionalities and behaviour of the enterprise. These are stand-alone processes triggered by means of Events and governing the way Enterprise Activities (i.e. basic functionalities) are executed according to so-called Behavioural Rules and Declarative Rules to produce a given result (Function Output). Declarative and Behavioural Rules represent business know-how (i.e. business procedures, policies or rules). Enterprise Activities use, process and create enterprise objects defined in the model as Object Views (physical objects or information entities). To ease the structuring of the model CIMOSA also provides the concept of Business Process, which makes it possible to decompose a Domain Process into (re-usable) sub-processes (the Business Processes).

Figure B6-1000/1: Generic Building Blocks of the Requirements Definition Modelling Level and their Relationships

In addition CIMOSA provides means for structuring the information used and produced during the operation into Enterprise Objects which together with the Object Relationships and applying Integrity Rule form the information model of the enterprise. Required Resources are described as required Sets of Capabilities leaving the choice of the real resource for the system design. Also described are design responsibility and authorisation for the different items of the model. This will ensure unambiguous model control during the complete model engineering life cycle with emphasis on model the maintenance.

Thus a fully defined Domain Process equates to a network of Enterprise Activities linked by Behavioural Rules with identification of all information, resource and organisational aspects needed in the course of its execution. This is an important feature of CIMOSA which provides one instantiated model of:

-	the flow of control (in the form of Behavioural Rules)

-	inputs and outputs of Enterprise Activities which are information entities (from which the flow of information can be derived)

-	inputs and outputs of Enterprise Activities which represent physical objects (from which the flow of materials can be derived)

-	identification of all resources needed providing the base for asset management

-	identification of organisational aspects (responsibility/authorisation) allowing engineering control throughout the system life cycle.

2.	Background Section

2.1	Examples (tbd)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Partial Requirements Definition Models
CIMOSA Technical Baseline

Partial Requirements Definition Models

B6-1100. Version: 1.0; Last Update: 94.07.08

1.	Technical Section

1.1	Purpose and Scope

Contains (partially) instantiated aggregations of generic constructs at the Requirements Definition Modelling Level, used to instantiate Particular Models.

1.2	Terms and Definitions

(1)	Partial Requirements Definition Models: contain sets of (partial) instances of Generic Building Blocks and Building Block Types structured to present a partial solution to problem areas in manufacturing enterprises. These partial solutions will be used as macro building blocks in the generation of Particular Requirement Definition Models.

1.3	Abbreviations and Acronyms (none)

1.4	Description

The instantiation of Particular Requirements Definition Models directly from the CIMOSA Generic Building Blocks and/or Building Block Types is not always desirable. Many enterprises of a given industry sector, size, and/or enterprises following the same manufacturing strategy have many characteristics in common. The Particular Requirements Definition of many enterprises will, as a consequence, have many parts in common. The purpose of the Partial Requirements Definition is therefore to capture this commonality; by including these in CIMOSA. These models can be retrieved and reused by individual companies in the creation of their Particular Requirements Definition Model to take advantage of previous work, reduce workload and design time and contribute to standardisation of manufacturing activities.

Partial Requirements Definition Models are not required to contain partial instances of any specific construct but are sets of classified, partially or fully instantiated definitions of one or more building block instances. In other words they can be any kind of consistent aggregation of building block instances.

2.	Background Section

2.1	Examples (tbd)

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Particular Requirements Definition Model
CIMOSA Technical Baseline

Particular Requirements Definition Model

B6-1200. Version: 1.0; Last Update: 94.07.08

1.	Technical Section

1.1	Purpose and Scope

Defines the Particular Requirements Definition Model of one individual enterprise.

1.2	Terms and Definitions

(1)	Particular Requirements Definition Model:

(a)	is a consistent instantiation of the CIMOSA Generic Building Blocks and Building Block Types or Partial Models for requirements definition in order to express the business requirements of a particular Enterprise.

(b)	A Particular Requirements Definition Model is unique to a given enterprise, and as such does not form part of the CIMOSA Reference Architecture.

1.3	Abbreviations and Acronyms (none)

1.4	Description

The Particular Requirements Definition Model equates to the Requirements Definition Model of the operational system of one individual enterprise or part thereof. It can be generated by the use of the Generic Building Blocks, Building Block Types and/or available Partial Models for requirements definition. It can also be generated solely from the Generic Building Blocks for requirements definition.

The Particular Requirements Definition Model of a given enterprise is made of a mutually consistent set of instances of Generic Building Blocks and Building Block Types. It can be represented in two ways:

-	in structured textual form using description templates of the constructs defined at the Requirements Definition Modelling Level of the Reference Architecture;

-	in graphical form using the graphical representation of the same constructs (optional).

1.4.1	Level of Detail of the Model

At the Requirements Definition Modelling Level the Particular Model does not have to be complete. This means that it is not necessary to define Enterprise Objects and Object Relationships or Organisation Cells. Only Object Views referred to in the Function View, their Information Elements and possibly applicable Integrity Rules have to be defined. This is called coarse requirements definition. However it is recommended to define the aggregation structures of the other Views (Information, Resource and Organisation) as well as to get a more precise model of the requirements and to consolidate the model of the enterprise. Especially this makes the derivation of the Conceptual Schema at the Design Specification Modelling Level more easy. This is called detailed requirements definition.

2.	Background Section

2.1	Examples (tbd)

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Design Specification Model
CIMOSA Technical Baseline

Design Specification Model

B7-1000. Version: 1.1; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Contains the constructs at the Design Specification Model Level, used to instantiate Partial and Particular Models.

1.2	Terms and Definitions

(1)	Design Specification Model:

(a)	consistent instantiation of CIMOSA Generic Building Blocks or Building Block Types and/or Partial Models (Partial Design Specification Model) for design specification in order to specify the system design of a particular Enterprise (Particular Design Specification Model).

(b)	contains all the functional, information, resource and organisational design specifications for an optimised operational enterprise system verifying the business requirements of an enterprise.

(c)	expresses the system design specifications using the CIMOSA Function, Information, Resource and Organisation Views.

(d)	provides both business user and system designer type representation

1.3	Abbreviations and Acronyms

CIM:	Computer-Integrated Manufacturing

RDM 	Requirement Definition Model

DSM	Design Specification Model

PDSM	Particular Design Specification Model

1.4	Description

The purpose of the Particular Design Specification Model (PDSM) is to provide support to:

-	improve the consistency and completeness of the business user requirements; remove any redundancy and ambiguity;

-	transform the user requirements into an implementable solution;

-	specify the necessary operations for each enterprise activity to be implemented;

-	test and investigate several potential solutions using computer simulation of the model;

-	obtain a consistent and optimised design model.

The Particular Design Specification Model specifies the proposed realisation(s) for the requirements defined in the Particular Requirements Definition Model. After the selection of a particular solution, it contains the specifications of the system to be implemented in order to realise the defined user requirements. While the Requirements Definition Model only deals with the definition of the functional structure of the enterprise, the Design Specification Model must deal with:

-	time

-	occurrences of some enterprise constructs

-	dynamic behaviour of some constructs (activities, information, resources) in the form of state diagrams

-	interaction between processes of the enterprise (co-operation, co-ordination or synchronisation mode)

These additional aspects are needed in order to:

-	fully specify enterprise functionality

-	define and analyse the enterprise state (behaviour)

-	analyse and predict system performance (qualitative and quantitative analysis)

-	provide support for computer simulation of part or totality of the Design Specification Model

CIMOSA provides a set of generic constructs which allow to model the design specifications of the enterprise operation or parts thereof deriving them directly from the business requirements definitions.

1.4.1	CIMOSA Design Specification Modelling

In the particular model Domain Processes, Business Processes and Enterprise Activities have been defined at the Requirements Definition Modelling Level. This model is the base for the Design Specification Model and its contents (the set of instantiated Generic Building Blocks, Building Block Types and Partial Models) is directly used in the design process. The contents of the constructs is reviewed at the Design Specification Modelling Level and may be restructured, amended and expanded to make sure that they are implementable.

At the Design Specification Modelling Level a more detailed specification of the enterprise system is required. Thus the user-oriented object-oriented model defined at the Requirements Definition Modelling Level is amended and enriched in order to allow specifications of system components. This will be achieved in different ways:

-	the contents of constructs defined in the Requirements Definition Model will be extended by providing additional entries in the templates asking for more detailed specifications

-	additional constructs may be provided (Resource View: Resource, Functional Entity)

-	construct may be amended by additional elements (Function View: Activity Behaviour, Functional Operation)

-	constructs may be translated into another representation (Information View: IT representation)

Figure B7-1000/1: Generic Building Blocks of the Design Specification Modelling Level and their Relationships

However, CIMOSA ensures model readability for the business user by either by keeping the original constructs and only amending requirements definition by additional information or by providing re-translation into those constructs (e.g. Object View vs. schema representation).

The Particular Design Specification Model is envisaged as being developed in six main stages:

(a)	Review of the Requirements Definition Model for ambiguities and inconsistencies

(b)	Identification of Resources providing the required Sets of Capabilities (optional Alternative Resources)

(c)	Functional Decomposition of Enterprise Activities, into Functional Operation and identification of the related Functional Entities (CIMOSA active resources)

(d)	Behaviour Analysis of the set of Functional Operations (Enterprise Activity Behaviour) (i.e. definition of time and sequence of actions of the resources identified)

(e)	Identification of Operational Responsibilities and Authorisation

(f)	Structuring of Information View (Conceptional Schema), Resource View (Cells) and Organisation View (Units and Cells)

Ideally, any time that the functional structure of the Design Specification Model requires restructuring, the Requirements Definition Model must be updated accordingly. In practice, this can be done at the end of major design phases when:

-	inconsistencies have been found in the requirements and need to be corrected

-	it is impossible to provide a sound technical solution for the requirements as currently expressed

-	new technologies are being considered as candidate solutions.

Figure B7-1000/1 shows these Generic Building Blocks and their relations between each other (*). Starting from the Requirement Definition Model all definitions are reviewed and amended as required in order to remove inconsistencies and to correct ambiguities. In the next step Resources are identified which provide their Defined Capability Sets and thereby satisfy the Capability Sets defined for Enterprise Activities. Resource specification may include several options (Alternative Resources) to be evaluated at design time or left as alternatives at run time. Therefore the system design may still contain Alternative Specified Resources proving their Specified Capability Sets. Alternatives are defined as far as necessary to make a technical choice with the specifications defined as detailed as required to make a product selection.

Furthermore, Specified Enterprise Activities are further detailed and provided with a behaviour (Activity Behaviour) in terms of their so-called Functional Operations. These Functional Operations must be specified in relation to the specified active resource (Functional Entities) planned to be implemented for their execution. Concepts of time and enterprise states must therefore be introduced in the model in order to correctly specify the enterprise behaviour.

Time will be attached to Specified Events and duration times can be defined for Functional Operations and Enterprise Activities. This is required for performance analysis and computer simulation of the model. Computer simulation also requires the definition of occurrences of constructs. Quantitative analysis can be made on the basis of equivalent timed Petri nets.

Definition: The enterprise state is defined at a given instant in time by the state of the enterprise components (i.e. resources, activities, events and information).

The information model of Enterprise Objects is translated into the Conceptional Schema (IT related Construct) in the form of a semantic data model (expressed in terms of an extended entity-relationship model) at the Design Specification Modelling Level. However, the user view point will be kept by still providing Specified Object Views. These Object Views are represented internally through External Schemas and provided to the user via Database Transactions.

Organisational aspects are identified through specification of both Design and Operational Responsibility and Authorisation for all relevant model and enterprise entities, respectively. Structuring into Organisation Units and Organisation Cells will enable the creation of the enterprise organisation.

2.	Background Section

2.1	Examples (tbd)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(*)	Note: Generic Building Blocks and Building Block Types at the Design Specification Modelling Level are termed Specified in order to distinguish them from those at the Requirement Definition Modelling Level.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Partial Design Specification Model
CIMOSA Technical Baseline

Partial Design Specification Model

B7-1100. Version: 1.0; Last Update: 94.07.08

1.	Technical Section

1.1	Purpose and Scope

Contains (partially) instantiated aggregations of generic constructs at the Design Specification Modelling Level, used to instantiate Particular Models.

1.2	Terms and Definitions

(1)	Partial Design Specification Models: contain sets of (partial) instances of Generic Building Blocks and Building Block Types structured to present a partial solution to problem areas in manufacturing enterprises. These partial solutions will be used as macro building blocks in the generation of Particular Design Specification Models.

1.3	Abbreviations and Acronyms (none)

1.4	Description

Many enterprises of a given industry sector, size, and/or enterprises following the same manufacturing strategy have many characteristics in common. The Particular Design Specification Models of many enterprises will, as a consequence, have many parts in common. The purpose of the Partial Design Specification Models is therefore to capture this commonality; by including these in CIMOSA. Individual enterprises will be able to start from a basis much closer to their needs, taking advantage of previous work performed in the creation of the Partial Models, and significantly reducing the workload, the individual companies would need to expend.

Partial Design Specification Models are not required to contain partial instances of any specific construct but are sets of classified, partially or fully instantiated, definitions of one or more building block instances. In other words they can be any kind of consistent aggregation of building block instances.

2.	Background Section

2.1	Examples (tbd)

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Particular Design Specification Model
CIMOSA Technical Baseline

Particular Design Specification Model

B7-1200. Version: 1.0; Last Update: 94.07.08

1.	Technical Section

1.1	Purpose and Scope

Defines the Particular Design Specification Model of one individual enterprise.

1.2	Terms and Definitions

(1)	Particular Design Specification Model:

(a)	is a consistent instantiation of CIMOSA Generic Building Blocks and Building Block Types or Partial Models for design specification in order to specify the static and dynamic properties of the operational system of a particular Enterprise.

(b)	A Particular Requirements Definition Model is unique to a given enterprise, and as such does not form part of the CIMOSA Reference Architecture.

1.3	Abbreviations and Acronyms (none)

1.4	Description

The Particular Design Specification Model is the Design Specification Model of the operational system of one individual enterprise or part thereof. It is derived from the Particular Requirements Definition Model by amending the definition according to the extended set of Generic Building Blocks, Building Block Types and/or available Partial Models for design specification. It can also be generated solely from the Generic Building Blocks for design specification.

The Particular Design Specification Model of a given enterprise is made of a mutually consistent set of full instances of Generic Building Blocks and Building Block Types. It can be represented in two ways:

-	in a structured, computer-processable, textual form using description templates of the constructs of the Design Specification Modelling Level;

-	in a graphical form using the graphical representation of the same constructs (optional).

1.4.1	Level of Detail of the Model

At the Design Specification Modelling Level the Particular Model must be complete and the level of detail has to be sufficient to support the selection of components especially of Resources and Functional Entities. In addition the model must be at least computer processable, but ideally computer executable, to support consistency checking, computer simulation, validation and performance analysis of the model. Thus each construct of the model must be amenable to a formal description in a computer processable language.

2.	Background Section

2.1	Examples (tbd)

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Implementation Description Model
CIMOSA Technical Baseline

Implementation Description Model

B8-1000. Version: 1.1; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Contains constructs at the Implementation Description Modelling Level, used to instantiate Partial and Particular Models.

1.2	Terms and Definitions

(1)	Implementation Description Models:

(a)	consistent instantiation of CIMOSA Generic Building Blocks or Building Block Types and/or Partial Models (Partial Implementation Description Model) for implementation description in order to describe the system implementation of a particular Enterprise (Particular Implementation Description Model).

(b)	contains all the functional, information, resource and organisational business implementation descriptions of a CIM system including exception handling conditions.

(c)	expresses the implementation descriptions of a CIM system using the CIMOSA Function, Information, Resource and Organisation Views.

(d)	provides both business user and system designer type representation

1.3	Abbreviations and Acronyms

RDM	Requirement Definition Model

DSM	Design Specification Model

IDM	Implementation Description Model

PIDM	Particular Implementation Description Model

1.4	Description

The purpose of the Particular Implementation Description Model (PIDM) is to provide support to:

-	record the real contents of the implemented operational system; identify deviations from the design specifications,

-	supplement the design specification with implementation relevant information,

-	validate and verify its contents to meet operational requirements,

-	validate and verify its contents enable consistent and unambiguous enterprise operation,

-	release the model for model driven operation control and monitoring.

The Particular Implementation Description Models is derived from the Particular Design Specification Model capturing all the differences between the system design and the system realisation. It uses classified, partially or fully instantiated, instances of Generic Building Blocks or Building Block Types at the Implementation Description Modelling Level. Figure B8-1000/1 shows these Generic Building Blocks and their relations between each other (*).

1.4.1	CIMOSA Implementation Description Modelling

Domain Processes, Business Processes, Enterprise Activities as well as Information, Resources and Organisation related items have been defined at the Particular Design Specification Modelling Level. This model contents is reviewed and compared with the progress during the implementation process . Any deviation from the system design has to be recorded in its appropriate place and if necessary the higher level models have to be up-dated as well. Ideally, any time that the functional structure of the Design Specification Model requires restructuring, the Requirements Definition and Design Specification Model must be updated accordingly. In practice, this can be done at the end of major design phases when:

-	it is impossible to provide a sound technical solution for the design as currently expressed

-	new technologies are being considered as candidate solutions

At the Implementation Description Modelling Level, run-time information for control of Domain Processes, Business Processes and Enterprise Activities must be defined on one hand, executable form of Functional Operations must be described and implemented on the other hand. Also exception handling mechanisms to face abnormal situations or random events must be provided. Furthermore, input and output ports must be defined to materialise the physical connections of the model (or Particular Architecture) with its real-world environment. Run-time information may require the use of global variables as well as shared memories for message exchange between Enterprise Activities.

Ports, variables, messages, shared memories and global exception handling mechanisms are declared in the Implemented Domain construct which defines the boundary of an executable environment made of Implemented Domain Processes executed by Resource occurrences. Implementation of some Functional Operations may require code generation if they have to be implemented in the form of programs or database transactions. Others can be described as scenarios to be followed by human operators (Human Functional Operations). Others may have to be implemented in some devices (Machine Functional Operations).

Figure B8-1000/1: Generic Building Blocks of the Implementation Description Modelling Level and their Relationships

CIMOSA continues to ensures model readability for the business user by either keeping the original constructs and only amending requirements definition and design specification by additional information or by providing re-translation into those constructs (e.g. Implemented Object View vs. Implemented External Schema representation). The Particular Implementation Description Model is envisaged as being developed following the life cycle phases of system development:

(a)	Buy/Build system components

(b)	Install system components

(c)	Verify system behaviour

(d)	Verify system meeting business requirements

(e)	Release system for model driven operation control and monitoring

2.	Background Section

2.1	Examples (tbd)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(*)	Note: Generic Building Blocks and Building Block Types at the Implementation Description Modelling Level are termed Implemented in order to distinguish them from those at the Requirement Definition Modelling Level.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Partial Implementation Description Model
CIMOSA Technical Baseline

Partial Implementation Description Model

B8-1100. Version: 1.0; Last Update: 94.07.08

1.	Technical Section

1.1	Purpose and Scope

Contains (partially) instantiated aggregations of generic constructs at the Implementation Description Modelling Level, used to instantiate Particular Models.

1.2	Terms and Definitions

(1)	Partial Implementation Description Models: contains sets of (partial) instances of Generic Building Blocks or Building Block Types structured to describe a partial implementation solution to problem areas in manufacturing enterprises. These partial solutions will be used as macro building blocks in the generation of Particular Implementation Description Models.

1.3	Abbreviations and Acronyms (none)

1.4	Description

Partial Implementation Description Models are made of classified, partially or fully instantiated, instances of Generic Building Blocks or Building Block Types of the Implementation Description Modelling Level.

These models can be retrieved and reused as macro building blocks by individual companies in the creation of their Particular Implementation Description Model in order to take advantage of previous work, reduce workload and design time. Particular enterprises can also contribute to standardisation of manufacturing activities by making available some of their partial models.

2.	Background Section

2.1	Examples (tbd)

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Particular Implementation Description Model
CIMOSA Technical Baseline

Particular Implementation Description Model

B8-1200. Version: 1.0; Last Update: 94.07.08

1.	Technical Section

1.1	Purpose and Scope

Describes the Implementation Description Model of one individual enterprise.

1.2	Terms and Definitions

(1)	Particular Implementation Description Model:

(a)	a consistent instantiation of CIMOSA Generic Building Blocks or Building Block Types for the implementation description in order to describe how business operations of a particular Enterprise are implemented and executed.

(b)	is unique to a given enterprise, and as such does not form part of CIMOSA Reference Architecture.

1.3	Abbreviations and Acronyms (none)

1.4	Description

The Particular Design Specification Model is the Design Specification Model of the operational system of one individual enterprise or part thereof. It is derived from the Particular Requirements Definition Model by amending the definition according to the extended set of Generic Building Blocks, Building Block Types and/or available Partial Models for design specification. It can also be generated solely from the Generic Building Blocks for design specification.

The Particular Design Specification Model of a given enterprise is made of a mutually consistent set of full instances of Generic Building Blocks and Building Block Types. It can be represented in two ways:

-	in a structured, computer-processable, textual form using description templates of the constructs of the Design Specification Modelling Level;

-	in a graphical form using the graphical representation of the same constructs (optional).

1.4.1	Level of Detail of the Model

At the Implementation Description Modelling Level the Particular Model must describe the reality to a degree that the model execution reflects the behaviour of the real system and can be used for model driven enterprise operation control and monitoring. Therefore, the model must be computer executable, to support consistency checking, computer simulation, validation and performance analysis of the model. Each construct of the model must be amenable to a formal description in a computer processable language.

2.	Background Section

2.1	Examples (tbd)

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


CIMOSA Model Levels
 CIMOSA Outline

 Table of Contents

 Business Oriented Modelling

 CIMOSA Modelling Levels

 CIMOSA Models

 Requirements Definition Model

 Partial Requirements Definition Models

 Particular Requirements Definition Model

 Design Specification Model

 Partial Design Specification Model

 Particular Design Specification Model

 Implementation Description Model

 Partial Implementation Description Model

 Particular Implementation Description Model

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Function View, Modelling Paradigm Requirements
CIMOSA Technical Baseline

Function View, Modelling Paradigm Requirements

B1-1000. Version: 3.3; Last Update: 96.02.02

1.	Technical Section

1.1	Purpose and Scope

Defines the set of criteria that the CIMOSA Function View Modelling Paradigms must satisfy to model functions of an enterprise.

1.2	Terms and Definitions

(1)	Function View, Modelling Paradigm Requirements

(a)	to represent a framework for modelling of enterprise operations at the various CIMOSA Modelling Levels and at a sufficient degree of details allowing for the following very essential capabilities in enterprise modelling (see B1-2000 Function View Modelling Paradigms):

-	execution of the resulting Particular Implementation Description Model for control of totality or part of enterprise operations,

-	consistent computer simulation of enterprise models at various levels of abstraction (different planning horizons and different levels of functional decomposition),

-	clear separation between functionality and behaviour of enterprise,

-	efficient modelling of enterprise behaviour, including modelling of precedence relationships, parallelism, branching or decision-making control structures and iterations,

-	easy extension of models in both directions, higher levels of abstraction and levels of more details,

-	improved upward and downward traceability of all objectives and constraints as well as inputs and outputs used in the modelling process whenever necessary,

-	compatibility with previous approaches already in use in industry or being considered by standardisation bodies.

(b)	must at least consist of:

-	a function decomposition principle,

-	a modelling methodology which is part of the CIMOSA System Life Cycle,

-	a representation formalism defining the modelling constructs.

1.3	Abbreviations and Acronyms (none)

1.4	Description

1.4.1	Introduction

The Modelling Paradigms are a vehicle to define a "language". A "language" is a set of consistent and complementary building blocks covering a specific universe of discourse (shop floor, development, management, finance, others) which can be used to model a specific system. At each Modelling Level there are several available "languages" which could be used, and several more which will be developed in the future. The CIMOSA Reference Architecture is capable of encompassing all current and future "languages" by providing a framework into which they can fit.

Function View Modelling Paradigms define the "languages" which are available at the three different Modelling Levels. At each level the "language" which is to be used will be chosen from a list of approved "languages" specified by the three Function View Modelling Paradigms. The "language" chosen at one Modelling Level could impact on the choice of "language" at another level. The CIMOSA Function View Modelling Paradigms will consist of a structured, open set of primitive and high-level concepts, models, languages, methods and methodologies which can be used to describe the static and dynamic properties of the functionality and behaviour of Physical and Decision Systems of manufacturing Enterprises, i.e. to model the Function View at the Partial and Particular Levels of these Enterprises. The CIMOSA Function View Modelling Paradigms must be sufficiently flexible (or open) to allow for other languages to be recognised and incorporated within the framework.

1.4.2 Requirements Definition Modelling Level Paradigm

At the Requirements Definition Modelling Level the modelling paradigm must allow the:

-	definition of global functional requirements as perceived by top-management and/or

-	definition of very detailed functional requirements according to the needs of the business.

Hence the concept of Domain needs to be used to specify which subset(s) of the Enterprise will be the focus of analysis for the purpose of enterprise automation and integration. Then a function decomposition principle is required to break down objectives, constraints, business rules and the functional structure (functionality and behaviour) of each Domain of the enterprise in terms of events, processes, activities and associated declarative and procedural rules. The level of details of the functional requirements definition will be decided by the CIM users. This Modelling Level will at least require computer animation to validate the process behaviour as defined by the business users.

1.4.3 Design Specification Modelling Level Paradigm

At the Design Specification Modelling Level, the modelling focus will essentially concern precise specifications of business processes and activities to be implemented on one hand and full specifications of activity operations on the other hand. However, constructs from the Requirements Definition Model will be kept to allow representation of the Design Specification Model to the business user in his modelling language.

The purpose of this modelling level is to:

-	improve the consistency and completeness of the business user requirements; remove any redundancy and ambiguity;

-	transform the functional user requirements into a system design solution;

-	specify the necessary operations for each enterprise activity to be implemented;

-	test and investigate several potential solutions using computer simulation of the model;

-	obtain a consistent and "optimised" (i.e. as efficient as possible) design model (according to the enterprise criteria).

The model must also deal with such issues as:

-	system states (i.e. the time dimension and occurrences of functions must be taken into account);

-	activity and operation occurrence synchronisation (message passing, synchronous and asynchronous working mode, etc.).

The system state is defined at a given instant in time by the state of the occurrences of its activities (and their operations), the state of the resources being employed and the state of its information system. Although it is obviously impossible to characterise all system states, it is important to be able to characterise the system state at given instants in time to study the dynamic behaviour of the enterprise or part of it). This Modelling Level will require a great deal of computer simulation to evaluate design alternatives.

1.4.4 Implementation Description Modelling Level Paradigm

At the Implementation Description Modelling Level, run-time information for control of business processes and activities as well as components for their execution must be defined on one hand and an executable form of activity operations must be described on the other hand. However, constructs from the Requirements Definition Model will be kept to allow representation of the Implementation Description Model to the business user in his modelling language.

The Function View of the Implementation Description Model of a Particular Architecture of an enterprise will be used by services of the Business Entity of the CIMOSA Integrating Infrastructure to control and monitor the execution of the business processes integrated by CIMOSA. At this level, physical input and output connections of the model with real-world entities must be defined. They are called ports.

Since manufacturing systems are prone to many random events perturbating their operations, an important issue to be addressed at the implementation level is exception handling. The model must be able to detect abnormal situations and react to these. When this is not possible or has not been foreseen but is detected by the services of the Integrating Infrastructure executing the model, control is passed to the responsible entity of the current process identified in the Organisation View.

1.4.5	General Constraints

-	Concepts, tools and methods incorporated in the CIMOSA Function View Modelling Paradigms must be based on industrial state-of-the-art developments or industrial standards.

-	Basic constructs and concepts of the CIMOSA Function View Modelling Paradigms must enable the description of the Function View of the enterprise completely and without ambiguity.

-	Formal languages (graphical or textual) can be used to express some of these constructs.

2.	Background Section

2.1	Examples

-	Parts of a Function View Modelling Paradigm are defined by: IDEF methodology (Bravoco and Yadav, 1985a, 1985b), GRAI methodology (Doumeingts, 1984), SADT tools (Ross, 1977), etc. However, as far as we know, no complete Function View Modelling Paradigm has currently been specified. Hence there is the need for developing a Function-Behaviour-Structure Paradigm.

-	Function description techniques: functional decomposition, activity diagrams, GRAI nets, actigrams, Petri nets, process nets, GRAFCET, etc.

-	Formal functional languages: GRAFCET, IDEF0 and IDEF2, etc.

2.2	Document References

1.	Bravoco, R.R. and Yadav S.B., 1985a, Requirements definition architecture - An overview. Computers in Industry, 6(1), 237-251.

2.	Bravoco, R.R. and Yadav S.B., 1985b, A methodology to model the functional structure of an organisation. Computers in Industry, 6(1), 345-361.

3.	Doumeingts, G., 1984, Méthode GRAI: Méthode de Conception des Systèmes de Productique. Thèse d'Etat, University of Bordeaux, France.

4. 	Mayer, R.J., Cullinane, T.P., deWitte, P.S., Knappenberger, W.B., Perakath, B., Wells, M.S., 1992. Information Integration for Concurrent Engineering (IICE) IDEF3 Process Description Capture Method Report. Air Force Systems Control, Wright-Patterson Air Force Base, Ohio 45433, AL-TR-1992-0057.

5.	Ross, D.T., 1977, Structured analysis for requirements definition. IEEE Transactions on Software Engineering, SE-3(1), 6-15.

2.3	Open Issues (none)

(c)  1993 - 1995 CIMOSA Association. All rights reserved.


Function View Modelling Paradigms
CIMOSA Technical Baseline

Function View Modelling Paradigms

B1-2000. Version: 3.4; Last Update: 96.02.02

1.	Technical Section

1.1	Purpose and Scope

Provides the definition of a "language" for all CIMOSA Function View Modelling Levels to describe the static and dynamic functional properties of the enterprise.

1.2	Terms and Definitions

(1)	CIMOSA Function View Modelling Paradigm: a structured, open set of primitive and high-level concepts, models, languages, methods and methodologies which are used to describe the static and dynamic properties of the Physical and Decision Systems of manufacturing Enterprises, i.e. to model the functionality, behaviour and functional structure of the Function View of Enterprises at the Partial and Particular Levels (see also B1-1000 Function View, Modelling Paradigm Requirements and B1-2100. Function-Behaviour-Structure Methodology).

1.3	Abbreviations and Acronyms

FBS:	Function-Behaviour-Structure Paradigm

GRAI:	Graph of Results and Activities Interrelated

IDEF:	ICAM DEFinition

SADT:	Structured Analysis and Design Technique

1.4	Description

1.4.1 Introduction

An Enterprise is a dynamic system. As such it must be described in terms of its structure, its functionality and its behaviour (i.e. its dynamics) in its proper context, i.e. according to its own objectives, constraints, rules, capabilities and states.

The CIMOSA Modelling Paradigms used in the Function View are frameworks for open modelling of Enterprises at the various CIMOSA Modelling Levels and at a sufficient degree of details. They satisfy the very essential capabilities in enterprise modelling as described in the Function View Modelling Paradigm Requirements item of the Formal Reference Base.

A CIMOSA Function View Modelling Paradigm consists of:

-	a function decomposition principle.

-	an event-driven, process-based, modelling methodology based on the central concept of separation of enterprise functionality and behaviour.

-	a representation formalism defining the modelling constructs.

Central to the paradigm is the concept of function decomposition in terms of functionality, behaviour and functional structure of the enterprise. This is intended from top to bottom of the Function View. To achieve this, AMICE has designed a Function-Behaviour-Structure (FBS) Paradigm to satisfy the requirements imposed on the Function View Modelling Paradigm.

This is an event-driven modelling paradigm which is based on the so-called Process/Activity/Operation approach (Vernadat and Zelm, 1991) described in the Function-Behaviour-Structure Paradigm item. The Enterprise is seen as a collection of Domains (i.e. well-defined areas of functionality) containing stand-alone but interacting Domain Processes which are triggered by unsolicited or planned enterprise Events (internal or external to the enterprise). Domain Processes are made of sub-processes, called Business Processes, and Enterprise Activities which perform the basic functionalitys using enterprise means. Enterprise Activities are made of elementary actions called Functional Operations which are executed by the Functional Entities of the Enterprise (as described in the Resource View).

This approach includes and extends previous functional modelling approaches such as SADT (Ross, 1977), IDEF0 (Bravoco and Yadav 1985a, 1985b), GRAI (Doumeingts, 1984) already in use in industry or being considered by standardisation bodies which essentially only recognise the concept of activity (also called function). The sets of Generic Building Blocks used in the CIMOSA Function View for each Modelling Level are:

Requirements Definition Modelling Level: Domain, Domain Relationship, Event, Domain Process, Business Process, Enterprise Activity, (Objective/Constraint, Declarative Rule)

Design Specification Modelling Level: Specified Domain, Specified Event, Specified Domain Process, Specified Business Process, Specified Enterprise Activity, (Objective/Constraint)

Implementation Description Modelling Level: Implemented Domain, Implemented Event, Implemented Domain Process, Implemented Business Process, Implemented Enterprise Activity, (Objective/Constraint)

Nota: Objective/Constraint and Declarative Rule are optional constructs in the sense that they can be defined by users either as pure text or in structured form (this is left open to users). They are provided in the form of Generic Building Blocks for the sake of genericity but they are always used as Building Block Components by other constructs. Objectives/Constraints defined at one modelling level are inherited by lower levels. Declarative Rules only exist at the Requirements Definition Modelling Level and constraint the definition of lower modelling levels (especially Process Behaviour and Activity Behaviour).

Domains, Events, Domain Processes, Business Processes and Enterprise Activities inherit properties from one modelling level to a lower level. Figure B1-2000/1 relates Generic Building Blocks of the Function View to one another (with no respect to the Modelling Levels). A general explanation of this figure follows.

Figure B1-2000/1: Generic Building Blocks of the Function View Modelling Paradigms

At the Requirements Definition Modelling Level CIMOSA describes what has to be done, and possibly how this could be done, for a given Enterprise in terms of Domains, Events, Domain Processes, Business Processes, Enterprise Activities and objectives, constraints and rules (Declarative Rules and Procedural Rules). Enterprise Activities represent pieces of functionality to be executed using enterprise means (they have no behaviour defined at this Modelling Level). Both Domain Processes and Business Processes have a behaviour (defined by a set of Procedural Rules) and may have a functional part defined for functionality breakdown. Domain Processes are high-level processes of the enterprise, i.e. real existing organisations of activities with functionality and behaviour. They are at the top level of the functional decomposition within Domains. They are not recursive. They are triggered by means of Events and nothing but Events. Business Processes are employed by Domain Processes or other Business Processes. They have a recursive nature.

At the Design Specification Modelling Level the requirements model constructs are extended by additional attributes to achieve precise specification of the implementation solution (in terms of Domain Processes, Business Processes and Enterprise Activities) which must be given (i.e. how the system must work to meet the requirements) and several solutions can be investigated. Especially, the functional decomposition is revisited and Enterprise Activities are further decomposed into elementary actions or units of work, called Specified Functional Operations. Time, process and activity synchronisation, resource requirements and system performance considerations must be taken into account.

At the Implementation Description Modelling Level, the design model constructs are extended by additional attributes (if required) to allow description of the actual implementation. The model describes how the system is going to be configured and is actually going to work. Thus run-time information for control of Business Processes and Enterprise Activities must be defined on one hand, executable form of (Implemented) Functional Operations must be described on the other hand and exception handling mechanisms must be provided to react to random events or exceptional situations.

CIMOSA aims to minimise the variety of instantiated building blocks. Thus the CIMOSA modellers must always keep in mind that Business Processes and Enterprise Activities are considered to form a common pool and can be re-employed by different Domain Processes and/or Business Processes. Reusability is a basic principle of CIMOSA in general.

Remark: Fully instantiated Domain Processes are not subject to reusability since they are supposed to be unique for a Domain (otherwise, since they are triggered by Events, their triggering conditions would be ambiguous). However, partial instantiated Domain Processes may well be reused (this is the basis of partial models).

1.4.2	General Constraints

-	Methodological steps and rules accompanying the CIMOSA Function View Modelling Paradigms for the Instantiation and Derivation Processes of the Function View are defined in the D-series Items.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	Bravoco, R.R. and Yadav S.B., 1985a, Requirements definition architecture - An overview. Computers in Industry, 6(1), 237-251.

2.	Bravoco, R.R. and Yadav S.B., 1985b, A methodology to model the functional structure of an organisation. Computers in Industry, 6(1), 345-361.

3.	Doumeingts, G., 1984, Méthode GRAI: Méthode de Conception des Systèmes de Productique. Thèse d'Etat, University of Bordeaux, France.

4.	Ross, D.T., 1977, Structured analysis for requirements definition. IEEE Transactions on Software Engineering, SE-3(1), 6-15.

5. 	Mayer, R.J., Cullinane, T.P., deWitte, P.S., Knappenberger, W.B., Perakath, B., Wells, M.S., 1992. Information Integration for Concurrent Engineering (IICE) IDEF3 Process Description Capture Method Report. Air Force Systems Control, Wright-Patterson Air Force Base, Ohio 45433, AL-TR-1992-0057.

6.	Vernadat, F., Zelm, M., 1991, Functional enterprise modelling: A Process/Activity/Operation approach. 6th Int. Conference on CAD/CAM, Robotics and Factories of the Future, London, UK, August 19-22, 1991, Volume II (H. Bera and R. Gill, Eds.), Southbank Press, London. pp. 194-200.

7.	Vernadat, F., 1993. CIMOSA: Enterprise modelling and integration using a process-based approach. In (H. Yoshikawa and J. Goossenaerts, eds.) Information Infrastructure Systems for Manufacturing, North-Holland, Amsterdam. pp. 65-84.

8.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

9.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1995 CIMOSA Association. All rights reserved.


Function-Behaviour-Structure Methodology
CIMOSA Technical Baseline

Function-Behaviour-Structure Methodology

B1-2100. Version: 3.3; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Provides of a functional decomposition principle and defines concepts of functionality, behaviour and functional structure in the description of enterprise tasks and operations.

1.2	Terms and Definitions

(1)	The Function-Behaviour-Structure (FBS) Paradigm provides:

(a)	a functional decomposition principle;

(b)	three building blocks to formally model functionality, behaviour and structure of the function part of a particular Enterprise;

(c)	an event-driven, process-based, modelling approach, called the process/activity/operation approach, to model tasks and sub-tasks of the Enterprise; and

(d)	a set of methodological rules to apply these constructs during the function decomposition process of a particular Enterprise

(2)	Enterprise Functionality is concerned with the objectives, constraints, function inputs and outputs, control inputs and outputs, resource inputs and outputs and transfer function of well-defined enterprise tasks to be realised in terms of basic operations (or actions) using enterprise means.

(3)	Enterprise Behaviour is concerned with the flow of control or the way processes and activities are employed over time in reaction to enterprise events and according to enterprise state to fulfil the business objectives under imposed constraints (financial, administrative or technical constraints or management declarative rules). This can be described by means of procedural rules defining control structures such as precedence relationships, parallelism, branching conditions and iterative processing.

(4)	Functional Structure of an enterprise is concerned with the functional decomposition of the enterprise into processes and sub-processes and activities, and then activities into operations.

1.3	Abbreviations and Acronyms

DP:	Domain Process

BP:	Business Process

EA:	Enterprise Activity

FBS:	Function-Behaviour-Structure Paradigm

1.4	Description

AMICE has defined a Function-Behaviour-Structure (FBS) Paradigm to support the Function View Modelling Paradigms. This paradigm is based on an event-driven, process-based approach, called the Process/Activity/Operation approach, and outlined as follows:

Within an enterprise tasks are usually organised into sub-tasks (which are generically called enterprise functions). They need to be realised to achieve the business objectives. In the Process/Activity/Operation approach an enterprise is seen as a collection of inter-related but non-overlapping Domains, which are subsets of the enterprise. These Domains can also have exchanges with Domains external to the enterprise. Each Domain will be impacted by (unsolicited) real-world happenings and requests to do something. Such happenings and requests originate within some other Domains (CIMOSA or not) and are described as Events of the enterprise. In reaction to these stimulus some enterprise functions are performed which can themselves be made of sub-functions. To represent tasks and actions performed within an enterprise CIMOSA forces users to think in terms of "processes", "activities" and "operations", where operations define the lowest level of granularity to represent tasks performed within an enterprise, activities are made of operations, and processes group activities (and may be sub-processes) to form logical chains of activities.

Operations are ignored at the Requirements Definition Modelling Level (to prevent considering excessive details) and are specified and described at the Design Specification and Implementation Description Modelling Levels of CIMOSA. Concepts of the Process/Activity/Operation approach are further detailed in the following sections.

1.4.1	Comparison Between Domain Process, Business Process and Enterprise Activity

A Domain is made of a non-empty set of Domain Processes and Resources (including Functional Entities) processing real-world objects. Each Domain Process is a stand-alone process made of a hierarchy of Business Processes (sub-processes) and Enterprise Activities. It contains at least one Enterprise Activity. The Business Processes just provide a convenient way for users to structure the model as easy manageable, re-usable, blocks to deal with complexity of their model.

In fact once completely designed a Domain Process equates to a network of Enterprise Activities which can be entered at several entry points under well-defined conditions (starting triggering conditions). Thus the most important constructs in this approach are Domain Processes and Enterprise Activities. Indeed one could very well design a correct model using only these two constructs.

Basic concepts	DP	BP	EA
Objectives	x	x	x
Constraints	x	x	x
Declarative Rules	x	x	x
Function Input	o	o	x
Function Output	o	o	x
Control Input	o	o	x	Functionality
Control Output	o	o	x
Resource Input	o	o	x
Resource Output	o	o	x
Required Capabilities			x
Ending Statuses		x	x
Behavioural Rules	x	x		Behaviour
Events	x
Where-Used		x	x	Structure
Employs	x	x
x: mandatory	o: optional
DP: Domain Process, BP: Business Process, EA: Enterprise Activity

Figure B1-2100/1: Construct Composition

The main differences between a Domain Process and a Business Process are that (1) a Domain Process has no parent structure (except the Domain to which it belongs), and (2) a Business Process is never triggered by Events only while Domain Processes are triggered by nothing than Events. Figure B1-2100/1 summarises these definitions.

Remark 1: In this paradigm, it becomes obvious that (1) Enterprise Activities essentially model pieces of enterprise functionality, (2) Business Processes essentially model (re-usable) blocks of enterprise behaviour, and (3) Domain Processes encapsulate enterprise functionality and behaviour contributing to the realisation of global business objectives.

Remark 2: The enterprise structure is directly represented within the constructs (Employs and Where-Used entries).

Remark 3: The paradigm allows for easy mutation of an Enterprise Activity into a Business Process and vice-versa.

Property 1: Separation of functionality and behaviour (one of the CIMOSA basic principles), making it possible to revise behaviour in order to meet changing circumstances without altering the installed functionality and vice-versa, is easily achieved.

Property 2: Traceability of objectives, constraints, Declarative Rules as well as of Function Inputs and Function Outputs is ensured from top to bottom of a functional decomposition.

Property 3: It is possible to assign a resource requirements to a set of Enterprise Activities, i.e. to a Business Process.

Property 4: For the sake of consistency the Ending Status of an enterprise function is a logical function of the Ending Statuses of its employed enterprise functions, except if it has no descendants.

Important Remark: Finally, it must be pointed out that the Function Input (respectively, Function Output) of a process (Domain Process or Business Process) does not equate to the sum of the Function Inputs (respectively, Function Outputs) of its sub-servant Enterprise Activities. The proof is that a Function Output of one Enterprise Activity can be the Function Input of another Enterprise Activity in the same process and therefore, does not belong to either the Function Input or the Function Output of that process.

2.	Background Section

2.1	Examples

The following example describes a functional decomposition in enterprise modelling as shown in Figure B1-2100/1. The process starts with the definition of an enterprise Domain or functional area, its contents and its relation to the outside world (definition of its boundaries). Its global functionality is then defined as a set of Domain Processes.

Figure B1-2100/2: Example of Function Decomposition

For each Domain Process its functionality part [F1] (identifying Function Input and Function Output if required) is described, as well as its behaviour part [B1] in terms of the lower level functionalities [F1x] which appear in the breakdown of the functionality of the Domain Process. The lower level functionalities [F1x] again will be defined as Enterprise Activities (EA) with the level of detail identified. If the described functionality has to be further detailed, the behaviour [B1x] will be described as Business Processes (BP) in terms of the lower level functionalities. This process can continue to any level of detail as desired by the business user.

Principle of use

Hierarchical definition does not mean that any given enterprise function is assigned to only one parent enterprise function. Any enterprise function (except Domain Processes) can be employed by any other enterprise function regardless of their relative positions in a design hierarchy. Thus specific enterprise functions (Business Processes or Enterprise Activities) can be re-used throughout a Particular Architecture leading to economy of design.

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1995 CIMOSA Association. All rights reserved.


Applicable Standards
CIMOSA Technical Baseline

Applicable Standards

B1-5000. Version: 2.2; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Provides the list of applicable standards to the CIMOSA Function View.

1.2	Terms and Definitions (none)

1.3	Abbreviations and Acronyms

CEN/CENELEC: 	Comité Européen de Normalisation/"-" Electrotechnique

ENV: 	European pre-Norm

GAM: 	Generic Activity Model

ISO: 	International Standards Organisation

1.4	Description

This item is intended to provide the list of applicable standards to the CIMOSA Function View.

So far no specific standard exists for functional enterprise modelling. However, work is in progress both at the European level (CEN/CENELEC WG ARC) and at the international level (ISO TC 184/SC5). CEN/CENELEC has produced the ENV 40 003 [1] which is a European pre-norm for enterprise modelling frameworks.

ISO has produced a Generic Activity Model (GAM) [2] and is currently working on a reference report on Enterprise Modelling [3]. The CIMOSA modelling approach is consistent with these ideas.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	ISO, 1986. The Ottawa Report on Reference Models for Manufacturing Standards, Version 1.1. ISO TC184/SC5/WG1 N51.

3.	ISO, 1993. Framework for Enterprise Modelling. ISO TC184/SC5/WG1 N300.

4.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1995 CIMOSA Association. All rights reserved.


Information View, Modelling Paradigm Requirements
CIMOSA Technical Baseline

Information View, Modelling Paradigm Requirements

B2-1000. Version: 4.2; Last Update: 94.07.08

1.	Technical Section

1.1	Purpose and Scope

Defines the set of criteria that the CIMOSA Information View Modelling Paradigms must satisfy to model all business data and information required for enterprise integration and operation.

1.2	Terms and Definitions

(1)	Information View, Modelling Paradigm Requirements

(a)	to represent a framework for modelling of enterprise information at the various CIMOSA Modelling levels as needed by the enterprise operations and at a sufficient degree of details allowing for the following very essential capabilities in enterprise information modelling (see B2-2000 Information View Modelling Paradigms):

-	an information modelling language adapted to users at the various CIMOSA modelling levels.

-	representation of data to be physically stored at and processed by several of the system components;

-	supporting data sharing among these components through a common, logical model that explicitly defines the structure, the constraints, and the operations that represent the semantic properties of information;

-	supporting integration of diverse activities in a factory requiring that the information model be rich in semantics (i.e. be defined in terms of an expressive set of basic constructs in order to correctly capture the meaning of real-world information);

-	supporting state-of-the-art data processing technology (currently, database technology) but be independent of any database implementation approach

-	accepting a large set of data types (as defined in the Data Type Capability item of the CIMOSA Formal Reference Base)

-	modelling of static and dynamic behaviour of information

-	object-oriented semantic information modelling language at the user level

-	SQL-like data definition language at system level (i.e. implementation level)

-	use of a non-proprietary semantic data language at the conceptual level

-	definition of sophisticated external views or schemata

-	description of a wide range of integrity rules and constraints

-	supporting the concept of database transactions

-	providing a complete implementable information model description

(b)	must consist of:

-	a basic framework complying with the three schema approach as defined by ANSI

-	a set of primitive concepts for information modelling, specification and access

-	rules to combine them into a set of constructs (or information modelling language) which can be used to describe the Information View of the CIMOSA Reference Architecture or the Information View of the Particular Architecture of an Enterprise

-	a set of methods to use the primitive concepts to describe the static and dynamic behaviour of information

1.3	Abbreviations and Acronyms

ANSI:	American National Standard Institute

SQL:	Structured Query Language

1.4	Description

1.4.1	General Description

Modelling Paradigms are a vehicle to define a "language". A "language" is a set of consistent and complementary building block types covering a specific universe of discourse which can be used to model a specific system. At each Modelling Level there are several available "languages" which could be used, and several more which will be developed in the future. The CIMOSA Reference Architecture is capable of encompassing all current and future "languages" by providing a framework into which they can fit.

Information View Modelling Paradigms define the "languages" which are available at the three different Modelling Levels. The "language" which is to be used will be chosen from a list of approved "languages" specified by the three Information View Modelling Paradigms. The "language" chosen at one Modelling Level could impact on the choice of "language" at another level. Currently, CIMOSA recognises only one "language" at each Modelling Level with emphasis on a common representation of the business user view (Object Views). Authorised organisations allowed to define such languages in the future will be AMICE and its follow-up organisations or standardisation bodies. The CIMOSA Information View Modelling Paradigm must be sufficiently flexible (or open) to allow for other languages to be recognised and incorporated within the framework.

Data and information described in the CIMOSA Information View of a Implementation Description Model of a Particular Architecture of an enterprise will be stored and managed by the various database and file systems of this enterprise. Data location, distribution and replication as well as integrity management and recovery control problems must be transparent to enterprise users and applications. This is the role of services of the Information Entity of the CIMOSA Integrating Infrastructure supporting the CIMOSA Information View.

1.4.2	General Constraints

-	Constructs must be independent of any specific (database) technology or any commercial product.

-	Constructs at the user level (Requirements Definition Modelling Level) must be as natural as possible.

-	Constructs of the Information Modelling Paradigms must enable the description of the conceptual, internal and external schemata of the Information View of a particular enterprise without ambiguity.

-	Formal languages (graphical or textual) are allowed to be used to express these constructs.

2.	Background Section

2.1	Examples

-	Information View Modelling Paradigms: ER methodology, DAFNE, IDEF-1, SAM-*, M* methodology, object-oriented paradigms, etc.

-	Information description techniques at the conceptual level: concepts such as Entity types, Relationship types, Attribute types or models such as ER models, Process and Data Net (PDN) models, Data Flow Diagrams, Object-Oriented Data Models, etc.

-	Formal information languages: SQL, QUEL, TAXIS, DAPLEX, COL, Transaction Definition Language, etc.

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1995 CIMOSA Association. All rights reserved.


Information View Modelling Paradigms
CIMOSA Technical Baseline

Information View Modelling Paradigms

B2-2000. Version: 5.4; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Provides the definition of a "language" for the CIMOSA Information View to model the business data and information required for enterprise integration and operation.

1.2	Terms and Definitions

(1)	CIMOSA Information View Modelling Paradigm: a structured, open set of primitive and high-level concepts, models, languages, methods and methodologies which are used to describe the static and dynamic properties of the Information System of manufacturing Enterprises, i.e. to model the Information View of Partial and Particular Models of Enterprises (see also B2-1000 Information View, Modelling Paradigm Requirements).

(2)	Object-Entity-Relationship-Attribute (OERA) Paradigm as used in CIMOSA: relies on the Generic Building Blocks as identified in Figure B2-2000/1:

1.3	Abbreviations and Acronyms

ANSI:	American National Standard Institute

ER:	Entity-Relationship

ERA:	Entity-Relationship-Attribute

OERA:	Object-Entity-Relationship-Attribute

PDN:	Process and Data Net

PRDM:	Particular Requirements Definition Model

SQL:	Structured Query Language

1.4	Description

1.4.1 Introduction

The Information View Modelling Paradigm is a common umbrella covering all the tools and methods necessary to build the Information View of a particular Enterprise, taking into account static and dynamic properties of data. In other words, it is a tool-kit and a set of methodological phases used to collect data and information requirements of the Enterprise as identified in the Function View (Inputs/Outputs of Enterprise Activities). This information is structured into a global model (called the Conceptual Schema), from which the implementation model (Internal Schema) of the Information View is derived. Thus, AMICE has selected the well-known ANSI/SPARC three schema architecture to satisfy the requirements for the Information View Modelling Paradigm of CIMOSA (ANSI/X3/SPARC, 1975). This provides tools and methods at the CIMOSA Requirements Definition, Design Specification, and Implementation Description Modelling Levels corresponding to the external level, the conceptual level and the internal level of the formalised Information System of the Enterprise. AMICE has selected the OERA Paradigm to satisfy the requirements of the CIMOSA Information View Modelling Paradigms. A global view of this framework is depicted by Figure B2-2000/1 and explained hereafter for the three Modelling Levels. While Object View, Enterprise Object, Object Relationship and Integrity Rule are more Business User oriented constructs, the other constructs are more Information Technology oriented constructs.

1.4.2. Requirements Definition Modelling Level

At the Requirements Definition Modelling Level, the CIMOSA Information View Modelling Paradigm makes use of a language which can be easily understood by the individuals who are non-computer literate employees of the Enterprise. The chosen language is a structurally object-oriented model and is based on the concepts of Enterprise Objects, Object Views of an Enterprise Object, Object Relationships, Information Elements and Integrity Rules. Configuration requirements on Enterprise Objects can be defined using the concepts of Version and Variant. Nota: Version and Variant are not Generic Building Blocks but CIMOSA terms.

Remark: Only Object Views, Information Elements and Integrity Rules are mandatory constructs of a PRDM. The definition of Enterprise Objects and Object Relationships is left open to the user. However, their modelling is recommended to make easier the derivation of the Conceptual Schema of the underlying information system as designed at the Design Specification Modelling Level.

1.4.3. Design Specification Modelling Level

Figure B2-2000/1: Generic Building Blocks of the Information View Modelling Paradigms

At the Design Specification Modelling Level, AMICE has currently chosen a semantic data model approach, the Entity-Relationship-Attribute (ERA) Methodology, for the description of the Conceptual Schema and of its External Schemata supporting the specification of (Specified) Object Views. Constraints on information and data are described by means of Integrity Constraints as derived from the Integrity Rules. Database Transactions describe the operations performed on the Conceptual Schema for data manipulation (i.e. the dynamics of data). Database Transactions are in fact specifications in the Information View of Data Storage Functional Operations defined in the Function View.

The Conceptual Schema, its External Schemata, the Database Transactions as well as the Integrity Constraints are all expressed at this modelling level in terms of the constructs of the ERA Methodology, namely Entity, Relationship, Attribute and Abstraction Hierarchies.

1.4.4. Implementation Description Modelling Level

At the Implementation Description Modelling Level, the CIMOSA Information View Modelling Paradigm makes use of a classical data model (the relational model) to describe the Internal Schema supporting the implementation description of (Implemented) Object Views. This schema is obtained using two successive schema derivation processes, one resulting in the Logical Data Model and the second one to produce an implementable (i.e. an executable) version of the data structure of the Internal Schema (also called Physical Data Model). In addition, Implemented External Schemata are provided as implementation descriptions of the External Schemata using a SQL-like data language. Database Transactions are implemented as Functional Operations.

Final implementation in the enterprise on data storage units of all parts of the Internal Schema can use any of the data models used by commercial systems (flat files, relational model, hierarchical structures, network models). Once implemented this must be transparent to the users (from the modelling point of view).

Important Remark: CIMOSA requires to model only information objects exchanged by at least two Enterprise Activities or Functional Entities and/or processed by Functional Entities of the model. However, the Business User is free to model all kinds of information s/he considers necessary.

1.4.5	General Constraints

-	Methodological steps and rules accompanying the CIMOSA Information View Modelling Paradigms for the Instantiation and Derivation Processes of the Information View are defined in the D-series Items.

-	Concepts, tools and methods incorporated in the CIMOSA Information View Modelling Paradigms must be based on industrial state-of-the-art developments or industrial standards.

-	Basic constructs and concepts of the CIMOSA Information View Modelling Paradigms must enable the description of the enterprise Information View completely and without ambiguity.

-	Formal languages (graphical or textual) can be used to express some of these constructs.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	ANSI/X3/SPARC Study Group on Database Management Systems, Interim Report 75-02-08. Available from ACM-SIGMOD, Vol. 7, No. 2, 1975.

2.	P.P.S. Chen, The entity-relationship model: toward a unified view of data, ACM Transactions on Database Systems, Vol. 1, No. 1, 1976. pp. 9-36.

3.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

4.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1995 CIMOSA Association. All rights reserved.


Applicable Standards
CIMOSA Technical Baseline

Applicable Standards

B2-5000. Version: 2.2; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Provides the list of applicable standards to the CIMOSA Information View.

1.2	Terms and Definitions (none)

1.3	Abbreviations and Acronyms

CEN/CENELEC: 	Comité Européen de Normalisation/"-" Electrotechnique

ENV: 	European pre-Norm

ISO: 	International Standards Organisation

GAM: 	Generic Activity Model

1.4	Description

This item is intended to provide the list of applicable standards to the CIMOSA Information View.

So far no specific standard exists for business information in enterprise modelling. However, work is in progress both at the European level (CEN/CENELEC WG ARC) and at the international level (ISO TC 184/SC5). CEN/CENELEC has produced the ENV 40 003 [1] which is a European pre-norm for enterprise modelling frameworks.

ISO has produced a Generic Activity Model (GAM) [2] and is currently working on a reference report on Enterprise Modelling [3]. The CIMOSA modelling approach is consistent with these ideas.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	ISO, 1986. The Ottawa Report on Reference Models for Manufacturing Standards, Version 1.1. ISO TC184/SC5/WG1 N51.

3.	ISO, 1993. Framework for Enterprise Modelling. ISO TC184/SC5/WG1 N300.

4.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1995 CIMOSA Association. All rights reserved.


Resource View, Modelling Paradigm Requirements
CIMOSA Technical Baseline

Resource View, Modelling Paradigm Requirements

B3-1000. Version: 1.2; Last Update: 94.07.08

1.	Technical Section

1.1	Purpose and Scope

Defines the set of criteria that the CIMOSA Resource View Modelling Paradigms must satisfy to model enterprise resources and their management.

1.2	Terms and Definitions

(1)	Resource View, Modelling Paradigm Requirements:

(a)	to represent a framework for modelling of enterprise resources at a sufficient degree of details at all CIMOSA Modelling Levels and include the following very essential modelling capabilities (see B3-2000 Resource View Modelling Paradigms):

-	efficient modelling of resource objects at various levels (e.g. enterprise, plant, area, cell, station, equipment),

-	differentiating between active and passive resources (*),

-	modelling of properties (static and dynamic) of resources, especially their provided capabilities, their class (passive or active),

-	modelling of properties of resources used for their management, especially their status, location, number of units, etc.

-	supporting matching between capabilities required by functions of the enterprise and capabilities provided by resources of the enterprise,

-	supporting resource selection and alternative choices of resources,

-	definition and description of resource management policies and exception handling procedures,

-	description of implemented resource objects, their location and connectivity resulting from the resource layout design,

-	consistent computer simulation of enterprise resources at various levels of abstraction (different planning horizons and different levels of functional decomposition),

-	supporting easy extension of models in both directions, higher levels of abstraction (aggregation) and levels of more details (decomposition),

-	supporting execution of the resulting Implementation Description Model of a Particular Architecture of an Enterprise for control of totality or part of enterprise resources,

-	compatibility with previous approaches already in use in industry or being considered by standardisation bodies.

(b)	The Resource View Modelling Paradigms must at least consist of:

-	a modelling methodology which is part of the CIMOSA System Life Cycle,

-	a representation formalism defining the modelling constructs.

1.3	Abbreviations and Acronyms (none)

1.4	Description

1.4.1 Introduction

The Resource View Modelling Paradigms define the "languages" which are available at the three Modelling Levels. The "language" to be used at each Level will be chosen from a list of approved "languages". These will be specified by the three Resource View Modelling Paradigms. The "language" chosen at one Modelling Level could impact on the choice of "language" at another Level. Currently, CIMOSA recognises only one "language" at each modelling level. More "languages" will be developed, accepted and used in the future. These will be based on the list of requirements established in section 1.2. Note, however, that CIMOSA is not responsible for developing these languages. These will be developed by industry through standardisation bodies.

The CIMOSA Resource View Modelling Paradigms will consist of a structured, open set of primitives, high-level concepts, models, languages, methods and methodologies. These can be used to describe the static and dynamic properties of the Resources of Physical and Decision Systems of manufacturing Enterprises, i.e. to model the Resource View at the Partial and Particular Levels of these Enterprises. The CIMOSA Resource View Modelling Paradigms must be sufficiently open (or flexible) to allow for other languages to be recognised and incorporated within the framework.

1.4.2 Requirements Definition Modelling Level Paradigms

At the Requirements Definition Modelling Level the modelling paradigm of the Resource View must allow

-	the definition of global resource requirements as perceived by top-management and

-	the definition of very detailed resource requirements in co-operation with interested users

for the part of the Enterprise to be modelled.

Hence the concept of Capability needs to be used to define the capabilities required by the Enterprise Activities of the Function View. These "required" capabilities represent the requirements for the Resources which will perform the Enterprise Activities.

1.4.3 Design Specification Modelling Paradigms

At the Design Specification Modelling Level, the modelling focus will essentially concern detailed analysis and precise specification of resource needs and management. Especially, it will cover:

-	the resource selection process according to required capabilities defined at the Requirements Definition Modelling Level

-	resource specification in terms of their type, structure and set of callable Functional Operations

-	support for resource layout design (including resource number per type, location and connectivity)

This Modelling Level may require a great deal of computer simulation for validating resource specification, deciding the number of resource units to be used and evaluating the performance of the system according to a given load of enterprise processes and activities to be executed.

1.4.4 Implementation Description Modelling Paradigms

At the Implementation Description Modelling Level, the modelling paradigm of the Resource View must concentrate on:

-	precise description of resource management policies to be used to execute processes and activities of the Function View

-	description of exception handling mechanisms for resource management (e.g. selection policy in the case of dynamic resource allocation)

-	precise description of Implemented Resources

1.4.5	General Constraints

-	Concepts, tools and methods incorporated in the CIMOSA Resource View Modelling Paradigms must be based on industrial state-of-the-art developments or industrial standards.

-	Basic constructs and concepts of the CIMOSA Resource View Modelling Paradigms must enable the description of the Enterprise Resource View completely and without ambiguity.

-	Formal languages (graphical or textual) can be used to express some of these constructs.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References (none)

2.3	Open Issues (none)

(*)	Active resources have a control device and can execute commands (e.g. a human operator, a robot, a database server, or any computer-controlled device) wile passive resources are not able to execute operations by themselves (they are used by active resources as components).

(c)  1993 - 1995 CIMOSA Association. All rights reserved.


Resource View Modelling Paradigms
CIMOSA Technical Baseline

Resource View Modelling Paradigms

B3-2000. Version: 1.4; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Provides the definition of a "language" for the CIMOSA Resource View to model resource requirements, management and connectivity to support enterprise integration and operation.

1.2	Terms and Definitions

(1)	CIMOSA Resource View Modelling Paradigm: a structured, open set of primitive and high-level concepts, models, languages, methods and methodologies which are used to describe the static and dynamic resource objects of manufacturing Enterprises and their management issues, i.e. to model the Resource View of Partial and Particular Models of Enterprises (see also B3-1000 Resource View, Modelling Paradigm Requirements).

1.3	Abbreviations and Acronyms

NC:	Numerical Control

RDM:	Requirements Definition Model

DSM	Design Specification Model

IDM	Implementation Description Model

1.4	Description

1.4.1	Introduction

Resources are enterprise objects used in support of the execution of Enterprise Activities of enterprise Domain Processes. They need to be allocated to those Enterprise Activities at certain dates for a given amount of time (resource scheduling problem).

The Resource View Modelling Paradigm provides a set of Generic Building Blocks and Building Block Types for modelling resource objects of the enterprise as well as their management policies. It also provides an unambiguous definition of the relationships which exist between Generic Building Blocks of the Resource View as well as those of other Views. The resulting Resource Modelling Paradigm must satisfy the following objectives:

1.	support efficient modelling of all resources of the enterprise, used to process Enterprise Activity Input into Output;

2.	distinguish between active resources (Functional Entities) and passive resource (Resource Components) (*);

3.	provide a basis for system optimisation of the Resources of the enterprise. It allows Resources to be modelled at different enterprise levels (e.g. enterprise, factory, area, cell, station) levels. It also allows other aspects (e.g., information flow, material flow, resource utilisation, bottleneck analysis) to be considered;

4.	provide a precise model of the implemented resources and their management;

5.	support the execution of processes of the Implementation Description Model of the Particular Architecture of an Enterprise.

More specifically, information from the Resource View of the Implementation Description Model is used in the Enterprise Operation Environment to support allocation, acquisition and assignment of Resources which are needed by Enterprise Activities of the Function View to transform Enterprise Activity Inputs into Outputs.

1.4.2 	Description

There is a strong relationship between the Resource View and the Function View because Resources provide the Capability Set required by the Enterprise Activities of the Function View.

The Resource View Modelling Paradigm is based on the following Generic Building Blocks:

-	Capability Set (**), which groups a set of capabilities required, provided or implemented

-	Resource, which is used to describe the nature, the set of provided Functional Operations and resource management needs of a (class of) resource units

In addition Address Topology is used as a Building Block Component to describe the connectivity of Resources (geographic or electronic) to one another. An occurrence of a Resource instance is called a Resource Unit (CIMOSA term but not a construct).

All resource occurrences used as Resource Input of some Enterprise Activity must be registered in the Implementation Description Model. Resource occurrences have a calendar defining their availability status on some time intervals (e.g. free, reserved, allocated, down or on maintenance). This information is a part of the Resource state. There can be several identical resource occurrences registered in a CIMOSA model. They will only differ by their object identifier (OID), their location and their state.

Figure B3-2000/2. Generic Building Blocks of Resource View Modelling Paradigm

Resources can be passive objects (e.g. a cart, a tool, a probe, etc.) or active objects (e.g. a human operator, a NC machine, a robot, a computer package, etc.). Active resources are called Functional Entities. They have some degree of intelligence and autonomy. They are characterised by the set of Functional Operations that they can execute. (Functional Operations are used in Activity Behaviour to specify Enterprise Activities).

A solution which dictates that a specific combination of Resource Units must be used to support an Enterprise Activity implies that the Enterprise Activity has been decomposed into a specific set of Functional Operations. During enterprise operation, resource allocation of Resource Units to Enterprise Activity occurrences is performed according to specifications provided by the Resource construct and resource management policies defined in the enterprise model. Resource Units are allocated to Enterprise Activity occurrences for the full duration of the execution Enterprise Activity occurrences. Figure B3-2000/1 depicts the Resource View Modelling Paradigm.

1.4.4 General Constraints

-	Methodological steps and rules accompanying the CIMOSA Resource View Modelling Paradigms for the Instantiation and Derivation Processes of the Resource View are to be defined in the D-series Items.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(*)	Active resources have a control device and can execute commands (e.g. a human operator, a robot, a database server, or any computer-controlled device) wile passive resources are not able to execute operations by themselves (they are used by active resources as components).

(**)	Note that Capability Set is used to describe:

- 	Capabilities required by the Enterprise Activities of the Function View

- 	Capabilities provided by the Resources of the Resource View

(c)  1993 - 1995 CIMOSA Association. All rights reserved.


Applicable Standards
CIMOSA Technical Baseline

Applicable Standards

B3-5000. Version: 0.3; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Provides the list of applicable standards to the CIMOSA Resource View.

1.2	Terms and Definitions (none)

1.3	Abbreviations and Acronyms (none)

CEN/CENELEC: 	Comité Européen de Normalisation/"-" Electrotechnique

ENV: 	European pre-Norm

ISO: 	International Standards Organisation

1.4	Description

This item is intended to provide the list of applicable standards to the CIMOSA Resource View.

So far no specific standard exists for resources  in enterprise modelling. However, work is in progress both at the European level (CEN/CENELEC WG ARC) and at the international level (ISO TC 184/SC5). CEN/CENELEC has produced the ENV 40 003 [1] which is a European pre-norm for enterprise modelling frameworks.

Relevant standards in resource modelling on the Implementation Description Modelling Level are MMS (Manufacturing Message Service) [2] and MAP (Manufacturing Automation Protocol) [3].

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	ISO, 1986. The Ottawa Report on Reference Models for Manufacturing Standards, Version 1.1. ISO TC184/SC5/WG1 N51.

3.	ISO, 1993. Framework for Enterprise Modelling. ISO TC184/SC5/WG1 N300.

4.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

5.	ISO 9506

6.	MAP 3.0 based on ISO 7498 (OSI Reference Model) and related Standards

2.3	Open Issues (none)

(c)  1993 - 1995 CIMOSA Association. All rights reserved.


Organisation View Modelling Paradigm Requirements
CIMOSA Technical Baseline

Organisation View Modelling Paradigm Requirements

B4-1000. Version: 2.3; Last Update: 94.07.08

1.	Technical Section

1.1	Purpose and Scope

Define the set of criteria and requirements that the CIMOSA Organisation View Modelling Paradigms must satisfy in order to model business organisational structures.

1.2	Terms and Definitions

(1)	Organisation View, Modelling Paradigm Requirements:

(a)	to represent a framework for modelling of enterprise operations at the various CIMOSA Modelling Levels and at a sufficient degree of detail allowing for the following very essential capabilities in enterprise modelling (see B4-2000 Organisation View Modelling Paradigms):

-	control, monitor and recovery for exception handling procedures for the execution of the resulting Particular Implementation Description Model for control of totality or part of enterprise operation;

-	representation of organisational structures especially concerning all organisational levels;

-	reprentation of decision making structures in terms of decision levels and decision centers,

-	identification of the run-time responsibilities for the management of, and authorities of operations on the entities defined in the Function, Information and Resource Views;

-	identification of responsibilities and authorities for design and maintenance (including updating and modification) of entities defined in the Function, Information and Resource View;

-	consistent computer simulation of enterprise models at various levels of abstraction (different planning horizons and different levels of functional decomposition as well as organisational structures);

-	easy extension of models in both directions, higher levels of abstraction and levels of more details;

-	compatibility with previous approaches already in use in industry or being considered by standardisation bodies, (ex. NIST AMRF model supported by ISO).

(b)	must at least consist of:

-	a modelling methodology which is part of the CIMOSA System Life Cycle,

-	a representation formalism defining the modelling constructs.

1.3	Abbreviations and Acronyms (none)

1.4	Description

1.4.1	Introduction

The Modelling Paradigms are a vehicle to define a "language". A "language" is a set of consistent and complementary building blocks which can be used to model a system. At each Modelling Level there are several "languages" available that could be used, and several more which will be developed in the future. The CIMOSA Reference Architecture is capable of encompassing all current and future "languages" by providing a framework into which they can fit.

The aim of the Organisation View is twofold:

(1)	to describe the organisational structure of the enterprise at various levels (factory, plant, area, cell, station) and

(2)	to define exception handling mechanisms to recover in case of wrong model execution at run-time (escape mechanism).

Organisation View Modelling Paradigms define the "languages" which are available at the three different Modelling Levels. At each level the "language" which is to be used will be chosen from a list of approved "languages" specified by the three Organisation View Modelling Paradigms. The "language" chosen at one Modelling Level could have an impact on the choice of "language" at another level. The CIMOSA Organisation View Modelling Paradigms will consist of a structured, open set of primitive and high-level concepts, models, languages, methods and methodologies which can be used to describe the static and dynamic properties of the structural organisation of the Decision System of manufacturing enterprises, i.e. to model the Organisation View at the Partial and Particular Levels of these Enterprises. The CIMOSA Organisation View Modelling Paradigms must be sufficiently flexible (or open) to allow for other languages to be recognised and incorporated within the framework.

Note: It is not the objective of the CIMOSA to model the very complexity of a human decision-making mechanism, but to describe a consistent system-wide decision-making organisation structure which allows human decisions to be taken consistently with respect to the global objectives of the enterprise. These decisions must be made by human (decision center) to cover not predefined activities and behaviours, exception handling or system failures. An implemented CIMOSA system will consist of two parts: one is computer executable part processing all possibly predefined activities and behaviours which are mainly procedural; the other is human based decision-making and organisational activities which must be executed in co-ordination with the computer executable part. The CIMOSA Organisation View must allow to model the links between these two parts, the organisational structure and decision activities concerned by the computer executable part.

1.4.2	Requirements Definition Modelling Level Paradigm

At the Requirements Definition Modelling Level the modelling paradigm must allow:

-	definition of global organisational requirements as perceived by management in terms of organisation hierarchies and decision levels;

-	definition of general organisational requirements in co-operation with interested users;

-	responsibilities and authorisation for creation and build-time modelling of Domain Processes, Business Processes, Enterprise Activities, Enterprise Objectives, Object Views and Capabilities defined in the Function, Information and Resource Views;

1.4.3	Design Specification Modelling Level Paradigm

At the Design Specification Modelling Level, the modelling focus will essentially concern precise specifications of organisational entities. The purposes of this modelling level are:

-	transform the organisational requirements at the Requirements Definition Modelling Level into a precise and complete specification of an operational organisational structure;

-	define the operational responsibilities and authorities in the relation to the Specified Domain Processes, Specified Business Processes, Specified Enterprise Activities, data entities, Functional Entities and Resources defined in the Function, Information Resource Views at the Design Specification Modelling Level;

-	map the decision centers (area of responsibilities and authorities) onto organisation units, and decision levels onto organisational levels;

-	gain consistency and completeness of the organisational structure to be designed;

-	test and investigate several potential solutions using computer simulation of the model;

-	obtain a consistent and optimised design model.

The simulation of organisational structures has to be done in connection with the simulation of the Function View.

1.4.4	Implementation Description Modelling Level Paradigm

Provide for recovery control procedures in the case of wrong model execution, exception handling  or restart situations at run-time. Modelling constructs defined in this level must allow:

-	refine the links between organisation units and executable entities defined in Function, Information and Resource Views in terms of responsibility and authorities;

-	be understandable by Integrating Infrastructure to trigger a concerned organisation unit in case of exception handling or any other human decision making.

1.4.5	General Constraints

-	Concepts, tools and methods incorporated in the CIMOSA Organisation View Modelling Paradigms must be based on industrial state-of-the-art developments of industrial standards.

-	Basic constructs and concepts of the CIMOSA Organisation View Modelling Paradigms must enable the description of the Organisation View of the enterprise completely and without ambiguity.

-	Formal languages (graphical or textual) can be used to express some of these constructs.

-	The constructs of the Organisation View are focused to the modelling of those aspects of the enterprise organisation, which are required for the execution of the enterprise model e.g.

-	 definition of the responsibilities for exception handling, or

-	 the authorities to execute functions or to access or modify data.

2.	Background Section

2.1	Examples (tbd)

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1995 CIMOSA Association. All rights reserved.


Organisation View Modelling Paradigms
CIMOSA Technical Baseline

Organisation View Modelling Paradigms

B4-2000. Version: 1.5; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Provides the definition of a "language" for the CIMOSA Organisation View Modelling Level to describe the organisational properties of the enterprise.

1.2	Terms and Definitions

(1)	Organisation View Modelling Paradigm: The CIMOSA Organisation View Modelling Paradigm is a structured, open set of primitive and high-level concepts, models, languages, methods and methodologies which are used for the modelling of enterprise organisation at the various CIMOSA Modelling Levels (see B4-1000 Organisation View Modelling Paradigm Requirements).

1.3	Abbreviations and Acronyms

OV:	Organisation View

FV:	Function View

IV:	Information View

RV:	Resource View

1.4	Description

There is currently no generally accepted "Image" which can be used at the Requirement Definition Modelling Level. Therefore, CIMOSA proposes a new "language". This language consists of a set of Generic Building Blocks which allows to describe and structure the organisational aspects of the enterprise:

1.4.1	Introduction

The Organisation View Modelling Paradigms define the constructs and their interrelationships for use in the Organisation View. It also describes an unambiguous relationship with the other Views (realised through the Generation Process). Above all there is a strong relationship between the Organisation View and the other Views, which is very important especially in terms of the integration of the CIMOSA model.

Figure B4-2000/1 illustrates the relationships among Generic Building Blocks used in the Organisation View as well as their relations with the other views.

Figure B4-2000/1: Generic Building Blocks of the Organisation View Modelling Paradigm

1.4.2.	Requirements Definition Modelling Level

At the Requirement Definition Modelling Level of the Organisation View, the assignment of activities from other CIMOSA Views to structural entities of the Organisation View has to be done in terms of design responsibility and areas of design authority within the Organisational Elements. The next step after this assignment has been done, consists of establishing an enterprise engineering organisational structure by defining relations between the different organisational structural entities applying the relevant guidelines. The links among the modelling constructs identified in Figure B4-2000/1 apply to the enterprise engineering activities at the Requirements Definition Modelling Level.

1.4.3.	Design Specification Modelling Level

At the Design Specification Modelling Level of the Organisation View, the assignment of tasks from the activities to structural entities of the Organisation View has to be done in terms of operational responsibility and areas of operational authority. The next step after this assignment has been done, consists of establishing an enterprise operational organisational structure by defining relations between the different organisational structural entities applying the relevant guidelines.

The assignment of Specified Organisational Elements to the Function, Information and Resource View proceeds by considering the cultural and political principles of the enterprise or part of it, taking into account also the assumptions of the Requirements Definition Modelling Level. The links among the modelling constructs identified in Figure B4-2000/1 apply to the enterprise operational activities at the Design Specification Modelling Level.

1.4.4.	Implementation Description Modelling Level (tbd)

1.4.5	General Constraints

-	Methodological steps and rules accompanying the CIMOSA Organisation View Modelling Paradigms for the Instantiation and Derivation Processes of the Organisation View are to be defined in the D-series Items.

-	Concepts, tools and methods incorporated in the CIMOSA Organisation View Modelling Paradigms must be based on industrial state-of-the-art developments or industrial standards.

-	Basic constructs and concepts of the CIMOSA Organisation View Modelling Paradigms must enable the description of the enterprise Organisation View completely and without ambiguity.

-	Formal languages (graphical or textual) can be used to express some of these constructs.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1995 CIMOSA Association. All rights reserved.


Applicable Standards
CIMOSA Technical Baseline

Applicable Standards

B4-5000. Version: 0.4; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Provide the list of applicable standards to the CIMOSA Organisation View.

1.2	Terms and Definitions (none)

1.3	Abbreviations and Acronyms

CEN/CENELEC: 	Comité Européen de Normalisation/"-" Electrotechnique

ENV: 	European pre-Norm

ISO: 	International Standards Organisation

1.4	Description

This item is intended to provide the list of applicable standards to the CIMOSA Organisation View. So far it includes no specific standards.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	ISO, 1993. Framework for Enterprise Modelling. ISO TC184/SC5/WG1 N300.

3.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues

1.	Various standards can be identified in the future.

(c)  1993 - 1995 CIMOSA Association. All rights reserved.


CIMOSA Views Contents
  CIMOSA Outline

 Table of Contents

 Business Oriented Modelling

 CIMOSA Views

 Function View, Modelling Paradigm Requirements

 Function View Modelling Paradigms

 Function-Behaviour-Structure Methodology

 Applicable Standards

 Information View, Modelling Paradigm Requirements

 Information View Modelling Paradigms

 Applicable Standards

 Resource View, Modelling Paradigm Requirements

 Resource View Modelling Paradigms

 Applicable Standards

 Organisation View Modelling Paradigm Requirements

 Organisation View Modelling Paradigms

 Applicable Standards

(c)  1993 - 1995 CIMOSA Association. All rights reserved.


Function View, Requirements Definition Modelling Level
CIMOSA Technical Baseline

Function View,

Requirements Definition Modelling Level

B11-1000. Version: 4.1; Last Update: 94.02.02

1.	Technical Section

1.1	Purpose and Scope

Provides the Function View constructs at the Requirements Definition Modelling Level and their relationships as perceived by the CIM system users.

1.2	Terms and Definitions

(1)	Function View, Requirements Definition Modelling Level:

(a)	is the Function View of the Requirements Definition Modelling Level as defined in the European Pre-norm (ENV 40 003).

(b)	consists-of:

-	non-empty-set-of Generic Building Blocks for requirements definition in the Function View and

-	set-of Building Block Types for requirements definition in the Function View and

-	set-of Partial Requirements Definition Models for the Function View and

-	one Particular Requirements Definition Model for the Function View.

1.3	Abbreviations and Acronyms

CEN/CENELEC: 	Comité Européen de Normalisation/"-" Electrotechnique

ENV:	European pre-Norm

CIM:	Computer Integrated Manufacturing

1.4	Description

At the Requirements Definition Modelling Level the Function View describes:

-	the global business requirements as perceived by top-management and

-	the detailed business requirements in co-operation with interested users.

The CIMOSA Function View is described by Function View Modelling Paradigms.

The Requirements Definition Modelling Level of the Function View is made of three sub-parts:

1.	The Generic Requirements Definition Building Blocks which form a structured catalogue of all Generic Building Blocks and Building Block Types of the Function View used for requirements definition;

2.	The Partial Requirements Definition Models which make up a structured catalogue of classified, (partially) instantiated aggregations of Function View generic constructs used to instantiate Particular Requirements Definition Models;

3.	The Particular Requirements Definition Model which contains all requirements definitions for the Function View of one individual enterprise.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	ENV 40 003: Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling. CEN/CENELEC, 1990.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Generic Building Blocks of the Function View, Requirements Definition Modelling Level
CIMOSA Technical Baseline

Generic Building Blocks of the Function View,

Requirements Definition Modelling Level

B11-2000. Version: 5.3; Last Update: 96.01.27

1.	Technical Section

1.1	Purpose and Scope

Provides the list of Generic Building Blocks of the Function View to be used in the CIMOSA Reference Architecture and the Particular Architecture for the definition of business user requirements.

1.2	Terms and Definitions

(1)	Generic Building Blocks of the Function View, Requirements Definition Modelling Level (ENV 12 204):

(a)	used to build Partial Requirements Definition Models and Particular Requirements Definition Model.

(b)	set of Generic Building Blocks and Building Block Types of the Function View. The former consists-of:

-	Objective/Constraint - O/C

-	Domain Process - DP

-	Domain - DM

-	Business Process - BP

-	Domain Relationship - RL

-	Enterprise Activity - EA

-	Event - EV

-	Declarative Rule - DC

(c)	set of Generic Building Blocks components of the Function View consists-of:

-	Function Input

-	Function Output

-	Control Input

-	Control Output

-	Resource Input

-	Resource Output

-	Behavioural Rule - BR

-	Ending Status - ES

1.3	Abbreviations and Acronyms

CEN: 	Comité Européen de Normalisation

ENV:	European pre-Norm

1.4	Description

An Enterprise is a dynamic system. As such it must be described in terms of its structure, its functionality and its behaviour (i.e. its dynamics) in its proper context, i.e. according to its own objectives, constraints, rules, capabilities and states. The CIMOSA Generic Building Blocks of the Function View at the Requirements Definition Modelling Level are used to build up the CIMOSA Function View Modelling Paradigm at this Modelling Level. The constructs of this modelling level are essentially used to define the problem. They do not deal with time and occurrences of constructs or system states.

In the Function View of the Requirements Definition Modelling Level CIMOSA describes what has to be done and possibly how this could be done in Enterprises in terms of Domains, Domain Relationships, Events, Domain Processes, Business Processes, Enterprise Activities and Declarative Rules.

Business objectives and constraints (expressed using the Objective/Constraint construct or in pure text) define the business orientations and limitations of the part of the enterprise analysed.

Domains identify well-defined, totally integrated, functional areas of the Enterprise.

Domain Relationships define interactions between two distinct Domains.

Events define solicited or unsolicited real-world happenings (including requests and orders as well as fixed clock times). They are used to initiate Domain Processes (and hence indirectly activate an employed Business Process/Enterprise Activity). They may also be used to condition the flow of control of a Business Process within a Domain Process (i.e. they can also be used in the triggering condition of a Business Process or Enterprise Activity).

Domain Processes are high-level processes defined as stand-alone processes triggered by some Events and producing a defined end result (Function Output). Domain Processes are at the top level of functional decomposition of Domains. They must be triggered by nothing else than Events.

Business Processes are sub-processes of Domain Processes. They cannot be directly triggered by Events only and are always called by a parent process.

Behaviour: Both Domain Processes and Business Processes have a behaviour (i.e. a flow of control defined by means of Behavioural Rules) and may have a functional part defined (i.e. inputs and outputs).

Figure B11-2000/1: Generic Building Blocks of the Function View and their Relationships at the Requirements Definition Modelling Level

Enterprise Activities describe basic enterprise functionalities (i.e. things to be done). They are defined by their Function Input, Function Output, Control Input, Control Output, Resource Input, Resource Output and Ending Status and have no behaviour defined at this Modelling Level. They are always called by a parent process. Events can be involved in their triggering condition.

Declarative Rules define imposed business rules constraining the design, implemen-tation or execution of Domain Proces-ses, Business Processes and Enter-prise activities.

Figure B11-2000/1 indicates the relations existing between the Generic Building Blocks of the Function View at the Requirements Definition Modelling Level.

1.5	Template (not applicable)

1.6	Building Block Types

The following list indicates Building Block Types needed for enterprise modelling:

-	Objective/Constraint Types

-	Domain Process Types

-	Domain Types

-	Business Process Types

-	Domain Relationship Types

-	Enterprise Activity Types

-	Event Types

-	Declarative Rule Types

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Domain
CIMOSA Technical Baseline

Domain

B11-2100. Version: 4.4; Last Update: 96.01.27

1.	Technical Section

1.1	Purpose and Scope

Defines the portion of the business that is being addressed, establishing the scope of a part of the particular model.

1.2	Terms and Definitions

(1)	Domain:

(a)	represents a subset of the enterprise (i.e. the universe of discourse) to be analysed and for which a CIMOSA compliant model will be created (i.e. instantiated).

(b)	is a construct used to establish the content and the boundary of the part of the enterprise which is subject to CIMOSA analysis based on a given set of business objectives and constraints (Domain Objective and Domain Constraint). It is made of a set of interacting Domain Processes, Events and Object Views (information objects and physical objects including resources).

1.3	Abbreviations and Acronyms

DM:	Domain

DP:	Domain Process

EV:	Event

OC:	Organisation Cell

O/C:	Objective/Constraint

OV:	Object View

OU:	Organisation Unit

RL:	Domain Relationship

1.4	Description

1.4.1	Introduction

Figure B11-2100/1: Domain Concepts

Domains describe the parts of the enterprise analysed and their relations with the outside environment from a high-level management-oriented point of view. This is opposed to Domain Processes which encapsulate the enterprise functionality and behaviour inside this Domain (i.e. a business professional-oriented description). The Domain concept has been introduced for overall requirements specification, i.e. problem and model scope definition.

At the Particular Level a Domain (Figure B11-2100/1) consists of a set of Domain Processes, which are intended to fulfil enterprise Objectives and comply with some imposed Constraints. Domain Processes receive/use/create Object Views. Domain Processes are triggered by means of Events (exogenous Events). The set of Domain Relationships concerning the same Domain forms the boundary of the Domain, describing the interactions between this Domain and other Domains (CIMOSA or non CIMOSA Domains, Domains inside or outside the enterprise) (*). Some Object Views (constructs of the Information View) and Events are involved in Domain Relationships which specify the interactions of a Domain with other Domains.

There is a need to distinguish between Non-CIMOSA Domains and CIMOSA Domains. A CIMOSA Domain represents the subset (i.e. the universe of discourse) of the enterprise to be analysed and for which a CIMOSA compliant model (part of the Implementation Description Model of the enterprise) has to be specified. Only CIMOSA Domains require to be fully described. Other Domains (Non-CIMOSA Domains) just need to be identified and can be described as incomplete Domain constructs . This is extremely important to interface CIMOSA models with existing enterprise models or non CIMOSA compliant systems (legacy systems) .

The Domain Processes of each CIMOSA Domain can later be further decomposed into Business Processes and Enterprise Activities, encapsulating groups of functions, users, groups of objects (including information, materials and resources) of an enterprise for the purpose of fulfilling a set of the major objectives of the enterprise. Domains are established when new designs or major changes occur in the business environment.

CIMOSA restricts the extent of changes, due to a redesign, to be within the borders of the Domain, which encapsulates all Business Processes, Enterprise Activities and Object Views related to the enterprise objectives to be achieved. It is important to mention that a Domain is not selected or defined by organisational boundaries, but is derived from the objectives given. Domain Processes and Domain Relationships are descriptions fully dependent on the existence of a CIMOSA Domain, i.e. if the Domain does not exist, they do not exist either. Only Object Views have, in general, independent existence apart from the one of a Domain since they can be exchanged by Domains. The Domain is a construct that in addition to its on header information only is a "Table of Contents" in the form of identifiers of Domain Objectives, Domain Constraints, Object Views, Events, Domain Processes (defining the content of the Domain) and identifiers of the Domain Relationships.

1.4.2	Domains and the System Life Cycle

Domain Processes are at the top level of the functional decomposition of a Domain and as such they will be expanded into a hierarchy of Business Processes and Enterprise Activities during the detailed CIMOSA analysis of the Domain.

Domain Objectives and Domain Constraints specify the scope and limitations of the Domain. They will be naturally broken down into sub-objectives and sub-constraints (associated to sub-functions) during the functional decomposition.

Object Views of a Domain (see Information View) represent objects (physical objects, information objects) received, used or sent by the Domain. They will provide a basis for the further definition of Function Input and Function Output of Domain Processes, Business Processes and Enterprise Activities involved in that Domain.

Events are all Events (endogenous or exogenous) related to the Domain.

1.4.3	Domain Design Practice: The Four Basic Principles

Figures B11-2100/2, B11-2100/3 and B11-2100/4: Domain Design Practice

CIMOSA aims to break down the classical artificial boundaries created by Taylorism approaches in enterprise organisation structures. CIMOSA goal is to provide efficient creation of enterprise organisation wealth. Thus, to achieve this goal the following four Domain design principles must be respected as much as possible.

Principle 1: Taylorism must be avoided, i.e. the boundary of a Domain does not map the organisational limits of physical units of a company, such as departments or plants or the like. Instead one must think in terms of a complete network of processes rather than in terms of function responsibilities. Never cut a management, operational and/or support Business Process by a Domain boundary.

Principle 2: Start CIMOSA with a well defined Domain, i.e. one containing full management, operational and/or support Processes. Then, expansion can be made in two ways:

-	make it bigger to include other Domain Processes (Horizontal expansion - see Figure B11-2100/2) or to integrate existing Domains (Upward expansion - see Figure B11-2100/3);

-	explode an Enterprise Activity further down (Downward expansion - see Figure B11-2100/4) in which B2 has been further decomposed into B21 and B22).

Principle 3: Avoid isolated function-oriented Domains by grouping as many closely inter-related and complete Domain Processes as possible in one Domain in order to avoid "big islands of automation". Avoiding creation of islands of automation must be a permanent concern of Domain designers.

Principle 4: Domains are not allowed to overlap, i.e. two distinct Domains cannot share a common Domain Process.

1.4.5	General Constraints

-	The largest Domain which can be defined in an enterprise is the enterprise itself, even including some of its subcontracting companies.

-	An enterprise can be decomposed into several, non overlapping but interrelated, Domains (also called adjacent Domains).

-	A given Domain Process (a fortiori a Business Process) must be fully contained within the boundary of the same Domain.

-	Domains are not allowed to overlap, i.e. two distinct Domains are not allowed to share the same Domain Process.

-	Each Domain must receive or send at least one exogenous Event. (It must not be a closed-world).

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Domain instances of all types are described by the following template:

DOMAIN

Header
Type: Identifier:  Name: Design Authority:	[relevant category - select from list] [DM-<unique identifier>] [name of Domain in the form: <adjective> <noun>, where <noun> relates to the functionality, <adjective> relates to the scope] [<identifier> / <name> of Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance]
Body
A. Descriptional Properties DOMAIN DESCRIPTION: CIMOSA COMPLIANT (**) DOMAIN COMPONENTS DOMAIN OBJECTIVES: DOMAIN CONSTRAINTS: DOMAIN PROCESSES: (OBJECT VIEWS) (****): (EVENTS): Relational Properties: BOUNDARY:	[short textual description of the Objectives and Constraints of the Domain and of Domain Processes required to achieve the Objectives;] ['yes' or 'no'] [non-empty list of <identifier (***)> / <name> of Objective/Constraint instances describing objectives to be fulfilled by the Domain instance; ] ['NIL' or list of <identifier> / <name> of Objective/Constraint instances describing constraints imposed on the Domain instance; ] [non-empty list of <identifier> / <name> of Domain Processes performed by the Domain instance. Can be left empty if CIMOSA compliance is 'no'] [non-empty list of <identifier> / <name> of all Object View instances, occurrences of which can be received, used or sent by occurrences of the Domain instance. Can be left empty if CIMOSA compliance is 'no'. Can be left empty for partial instances] [non-empty list of <identifier> / <name> of all Event instances, occurrences of which can be received, used internally or sent by occurrences of the Domain instance. Can be left empty if CIMOSA compliance is 'no'. Can be left empty for partial instances] [non-empty list of <identifier> / <name> of Domain Relationship instances between this Domain instance and other Domain instances. Can be left empty for partial instances]
2.	Background SECTION

2.1	Examples

DOMAIN:

Header
Type: Identifier: Name :  Design Authority :	Shop-Floor Operations/Batch-oriented DM-01 'Flexible Manufacturing Shop' OC-001 'Manufacturing Engineering'
Body
A. Descriptional Properties: DOMAIN DESCRIPTION: CIMOSA COMPLIANT: DOMAIN COMPONENTS DOMAIN OBJECTIVES: DOMAIN CONSTRAINTS: DOMAIN PROCESSES: OBJECT VIEWS: B. Relational Properties: BOUNDARY: EVENTS:	'Flexible Manufacturing Shop': Domain assigned to the Production of batches of parts with a medium degree of commonality (cylindrical shape, hard material), employing a set of metalworking machines and similar processing. Yes O/C-01 'Objective of Flexibility' O/C-02 'Objective of Cycle-Time' O/C-11 'Constraint on Resources' DP-01 'Order Management' DP-02 'Exception Management' ...... OV-001 'Workstation' OV-002 'Manufacturing Order' ..... RL-01 'Order Release' RL-02 'Shop Condition' ..... EV-01 'Order Management Request' EV-02 'Machine Failure' .....
2.2	Document References (none)

2.3	Open Issues (none)

(*)	Note: For all Domains there is only one occurrence, the Domain instance itself.

(**)	Must be 'No' for non-CIMOSA domain.

(***)	Constrained by the Domain Type.

(****)	Entries occur on Domain Process as well; consistency has to be assured.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Domain Objective
CIMOSA Technical Baseline

Domain Objective

B11-2110. Version: 4.2; Last Update: 96.01.27

1.	Technical Section

1.1	Purpose and Scope

Defines business goals as measurable and realistic end results for the enterprise's business to be performed in the Domain and the operational boundaries imposed by outside forces.

1.2	Terms and Definitions

(1)	Domain Objectives: define the business goals and required achievements imposed on the Domain, i.e. measurable and realistic desired end results for the enterprise's business. They express capabilities expected from the business environment represented by the Domain. They are enterprise objectives (*) representing goals pursued by the enterprise in order to fulfil some of its requirements. They are defined using the Objective/Constraint Generic Building Block.

(2)	Domain Objective: is-a Objective/Constraint.

1.3 Abbreviations and Acronyms

EO:	Enterprise Object

OC:	Organisation Cell

O/C:	Objective/Constraint

1.4	Description

The enterprise's business objectives are determined for that part of the enterprise which is to be modelled and implemented according to CIMOSA principles.

The objectives are specified in terms of such things as:

-	goals (budget, profit, revenue, return on investment)

-	strategic business plan (product groups, product prices, product volumes, markets, personnel, projects)

Domain Objectives are satisfied by Domain Processes. One Objective may be satisfied by several Domain Processes, and one Domain Process may contribute to the achievement of several Objectives. Domain Objectives must be (totally or partially) inherited by Domain Processes of the Domain. Although they will have the same representation at the Domain level, there is the need to differentiate between Domain Objectives and Domain Constraints due to their difference in nature and in scope. Objectives are enterprise wishes (especially in terms of capacity and performance) while constraints represent real-world limitations (cost constraints, organisational constraints, implementation constraints, and so on).

Domain Objectives are usually obtained directly from management authorities (directors, top managers, department heads, and the like). We can distinguish among two classes of objectives: qualitative objectives (defined by a textual statement only) and quantitative objectives (defined as a numeric constraint on some variable defined as an Information Element of the Information System). See examples.

Domain Objectives may be adjusted over the time and new ones may appear. Therefore, they have some validity dates (not known with exact precision at the Domain level of course) indicating that they hold from some date and/or they will hold until some other date or time period. Domain Objectives are described using the Objective/Constraint construct. They can therefore be defined as plain text statement or be formally defined in terms of an Information Element of an Enterprise Object (as defined in the Information View).

1.5	Description Templates (none)

Use template of Formal Reference Base item called Objective/Constraint.

2.	Background SECTION

2.1	Examples

1.	Objectives imposed on System Design:

- 	90% of deliverables must be on schedule

- 	Cost per Customer Order < 100 ECU

2.	Objectives imposed on System Operation (see template below):

- 	Daily Production Rate: at least 90% of total capacity

- 	Scrap Rate <= 5%

3.	Objectives on Product Design:

- 	Design Product for Ease of Use and Maintenance

4.	Objectives on production planning:

- 	Plan Production for Batch Size of 100

5.	Objectives on product manufacturing:

-	Manufacture Product with Minimum Turn-around-Time, Work-in-Process, Maximum Throughput

OBJECTIVE/CONSTRAINT

Header
Type: Identifier: Name: Design Authority:	Operational Objectives/Constraints O/C-02 'Daily Production Rate' OC-03 'Production Management'
Body
A.  Descriptional Properties: DESCRIPTION: SUBJECT: TARGET: VALUES: VALIDITY:  B. Relational Properties: INHERITED FROM:	scheduling of manufacturing resources should efficiently use available capacity EO-01 'Production Rate' Daily Production Rate, Scrap Rate Daily Production Rate: at least 90% of total capacity Scrap Rate <= 5% unlimited NIL
2.2	Document References (none)

2.3	Open Issues (none)

(*)	major enterprise objectives are part of the strategic business plan of the enterprise.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Domain Constraint
CIMOSA Technical Baseline

Domain Constraint

B11-2120. Version: 4.2; Last Update: 96.01.27

1.	Technical Section

1.1	Purpose and Scope

Defines business limitations on measurable and realistic desired end results for the enterprise's business to be performed in the Domain and the operational boundaries imposed by outside forces.

1.2	Terms and Definitions

(1)	Domain Constraints: describe enterprise constraints imposed on the Domain, expressing conditions restraining the range of possibilities of some enterprise's processes or entities within that Domain. They are defined using the Objective/Constraint Generic Building Block.

(2)	Domain Constraint: is-a Objective/Constraint.

1.3 Abbreviations and Acronyms

EO:	Enterprise Object

OC:	Organisation Cell

O/C:	Objective/Constraint

1.4	Description

The enterprise's business constraints are determined for that part of the enterprise which is to be modelled and implemented according to CIMOSA principles. The Domain Constraints are specified in terms of such things as:

-	limitations (investment limits, personnel limits, given locations, supplier availability, time requirements)

-	policies (scope of enterprise - make or buy, size of plants, plant location, supplier constraints, etc.)

-	risk taken or accepted

Domain Constraints are usually obtained directly from management authorities (directors, top managers, department heads, and the like). Domain Constraints must be (fully or partially) inherited by Domain Processes of the Domain. Domain Constraints may be adjusted over the time and new ones may appear. Therefore, they have some validity dates (not known with exact precision at the Domain level of course) indicating that they hold from some date and/or they will hold until some other date or time period. Domain Constraints are described using the Objective/ Constraint construct. They can therefore be defined as plain text statement (qualitative constraint) or be formally defined in terms of an Information Element of an Enterprise Object of the Information system (quantitative constraint).

1.5	Description Templates (none)

Use template of Formal Reference Base item called Objective/Constraint.

2.	Background SECTION

2.1	Examples

OBJECTIVE/CONSTRAINT

Header
Type:  Identifier: Name: Design Authority:	Design Objectives/Constraints OC-06 'Design Constraints' OC-002 'Product Engineering'
Body
A. Descriptional Properties: DESCRIPTION:  VALUES: VALIDITY: B. Relational Properties: INHERITED FROM:	Product design is constraint by the available budget and the manufacturing area available for product assembly Total Budget: maximum 2M ECU Plant Surface: limited to 2000 square meters Project Duration: From 01/89 Until last quarter of 96 NIL
2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Enterprise Activity
CIMOSA Technical Baseline

Enterprise Activity

B11-2200. Version: 4.4; Last Update: 96.01.27

1.	Technical Section

1.1	Purpose and Scope

Defines the "things to be done" as elementary tasks in terms of their inputs, their outputs and their function.

1.2	Terms and Definitions

(1)	Enterprise Activity:

(a)	describes a piece of functionality in the Function View of a particular enterprise at the Requirements Definition Modelling Level, i.e. "one of the things to be done".

(b)	is a construct which has a functional part and a structure part defined, but no behaviour part. It is employed by one or more Domain Processes and/or Business Processes but does not employ any Business Process or Enterprise Activity. It is characterised by the definition of its inputs, outputs (see list) and Ending Statuses.

- Function Input

- Control Input

- Resource Input

- Function Output

- Control Output

- Resource Output

(c)	Enterprise Activities of a particular Enterprise define elementary tasks to be performed in the Enterprise which consume inputs to produce outputs and need allocation of time and resources for the full duration of their execution.

1.3	Abbreviations and Acronyms

CS:	Capability Set

DR:	Declarative Rule

EA:	Enterprise Activity

OC:	Organisation Cell

O/C:	Objective/Constraint

OV:	Object View

OU:	Organisation Unit

1.4	Description

1.4.1	Generalities

Enterprise Activity is the basic construct in CIMOSA used to define pieces of enterprise functionality (i.e. things to be done). It is a central construct in the CIMOSA architecture in the sense that it federates a CIMOSA model because its legs (inputs/outputs) point to constructs of other modelling views and because it governs basic actions. By definition, an Enterprise Activity transforms its Function Input into Function Output using its Control Input and Resource Input and eventually producing Control Output and Resource Output. The constraints on this definition are:

-	the union set of Function Input, Control Input and Function Output (set of Object Views) cannot be empty

-	the intersection between Function Input and Control Input (sets of Object Views) must be empty

In practice, an Enterprise Activity is identified any time that an elementary task is identified in the enterprise model (i.e. which does not need to be further decomposed), which performs something (i.e. which transforms its Function Input into Function Output with respect to its Control Input) as described by some algorithm, and which will require allocation of time and resources for the full duration of its execution. The algorithm indicates how to perform the task in terms of a sequence of basic actions, called Functional Operations. The algorithm and the Functional Operations are specified at the Design Specification Modelling Level and not at the Requirements Definition Modelling Level (only a textual description of the task is given).

Figure: B11-2200/1: Enterprise Activity at Requirements Definition Modelling Level

A single pool of Enterprise Activities is shared by all Domain Processes and their Business Processes. Each Enterprise Activity in that pool is unique in that only one instantiation of an Enterprise Activity with the same inputs and outputs may exist but can be reused throughout the model. However, many occurrences of the same Enterprise Activity may be executed in the enterprise at the same time, competing for resources and sequenced in time. The execution of an occurrence of an Enterprise Activity is triggered by the processing of a set of Behavioural Rules which governs the flow of control (or enterprise behaviour) of the parent process of the activity.

An Enterprise Activity has no behaviour part (i.e. no Behavioural Rule set) at the Requirements Definition Modelling Level because it is not further decomposed at this modelling level. An Enterprise Activity is mainly defined by its functionality, i.e. its Function, Control and Resource Inputs and Outputs, on which its function operates as shown in Figure B11-2200/1 (*). Any Enterprise Activity must also be defined by its finite set of Ending Statuses. These are values defining all the possible termination states allowed for occurrences of this Enterprise Activity and used to control the execution of the set of Behavioural Rules in which the Enterprise Activity is involved.

All Enterprise Activities can terminate with one of the three basic statuses : 'FINISHED' (normal end), 'TERMINATED' (external termination) and 'ABANDONED' (internal termination). Each of these states can be further specialised by user-defined conditions which can take into account parts of the Function Output produced or not produced. (See Ending Status item of the Formal Reference Base).

In the course of a particular model development process, an Enterprise Activity can always be broken down into a further level of detail. Thus it becomes a Business Process. In this case, it is necessary to decompose the objectives and constraints and might be necessary to also decompose the various inputs and outputs. This is one of the main reasons why Business Processes have been provided with similar inputs and outputs than Enterprise Activities. According to the nature of Function Input and Output (information Object Views or physical Object Views) the flow of information and the flow of materials can be derived from a CIMOSA model from the definition of the Enterprise Activities. These two flows are independent of the flow of control represented by the sets of Behavioural Rules governing the sequence of execution of the Enterprise Activities of the model.

1.4.2	Triggering Conditions of Enterprise Activities

In the Enterprise Operation Environment an occurrence of an Enterprise Activity can be triggered by:

-	a calling occurrence of a parent structure (Domain Process or Business Process)

-	a triggering condition made of Ending Statuses only of previously completed functionalities

-	a triggering condition involving Ending Statuses of previously completed functionalities and occurrences of Events

Examples for each of these situations follow (See Behavioural Rule item for details on the syntax used):

When ON (START) DO EA1-1

(* usually used as a first rule in a set of Behavioural Rules employing the Enterprise Activity EA-1. START is the entry point in the set of rules *)

When (ES(EA-1) = value1) DO EA-2

(* EA-2 is triggered upon completion of EA-1 with Ending Status value1*)

When (ES(EA-2) = value2 AND ES(BP3) = value3) DO EA-4

(* EA-4 is triggered when both Enterprise Activity EA-2 finishes with Ending Status value2 and Business Process BP3 finishes with Ending Status value3 *)

When (ES(BP-4) = value4 AND Event2) DO EA-5

(* EA-5 is triggered when both conditions are true: BP-4 finishes with Ending Status value4 and an occurrence of Event2 has occurred *)

where ES(xy) is a standard function returning the value of the Ending Status of (xy).

1.5	Description Templates

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Enterprise Activity instances of all types are described by the following template.

ENTERPRISE ACTIVITY

Header
Type: Identifier: Name: Design Authority:	[relevant category - select from list <name>] [EA-<Unique Identifier>] [name of Enterprise Activity instance in the form: <adjective> <noun> <adjective>: qualifying the Enterprise Activity instance <noun>: related to the scope of the Enterprise Activity] [<identifier> / <name> of Organisation Unit and/or Organisation Cell with the authority to design/maintain this particular instance]
Body
A. Descriptional Properties  OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION: REQUIRED CAPABILITIES: INPUTS   FUNCTION INPUT:   CONTROL INPUT:   RESOURCE INPUT: OUTPUTS   FUNCTION OUTPUT:   CONTROL OUTPUT:   RESOURCE OUTPUT:   ENDING STATUSES: B. Relational Properties WHERE USED:	[non-empty list of <identifier> / <name> of objectives which must be fulfilled by the Enterprise Activity instance] ['NIL' or list of <identifier> / <name> of constraints applicable to this Enterprise Activity instance] ['NIL' or list of <identifier> / <name> of Declarative Rule instances applicable to this Enterprise Activity instance]  [textual description of the tasks performed by this Enterprise Activity; optional] ['NIL' or <identifier> / <name> of Capability Set defining required capabilities of occurrences of this Enterprise Activity instance] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Object View instances, occurrences of which are processed by occurrences of the Enter ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Object View instances, occurrences of which are used but not processed by occurrences of the Enterprise Activity instance]prise Activity instance] must be left undefined at this modelling level.]  ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Object View instances, occurrences of which are produced by occurrences of the Enterprise Activity instance] ['NIL' or list of <identifier> / <name> of Event instances, occurrences of which could be generated during the course of occurrences of the Enterprise Activity instance] ['NIL' or list of <identifier> / <name> of Object Views indicating requirements on data collection on resource usage] [non-empty list of Ending Status values and their signification in the form: <value> : <signification> where <value> is mandatory and is a 0-argument predicate and  <signification> is optional and is text] [non-empty list of <identifier> / <name> of Domain Process and/or Business Process instances employing this Enterprise Activity instance. Can be 'NIL' for partial instances]
Remark: By using the optional clause 'STREAM OF', Function Input, Function Output and Control Input can be defined either as a stream of Object Views (i.e. an unbounded flow of several occurrences received in sequence) or as one occurrence of each Object View type indicated.

1.6	List of Types

These types are only illustrative examples of families of Enterprise Activity Types that may eventually exists. They have not been approved as official CIMOSA Building Block Types so far.

Category 0	Category 1	Category 2	Category 3
Management Oriented	- Plan	- Analyse
		- Define
	- Control
	- Monitor	- Internal
		- External
	- Report	- Display
		- Hard copy
Operation Oriented	- Develop	- Design	- Draft
			- Detail
		- Qualify	- Simulate
			- Test
	- Produce	- Make	- Fabricate
			- Assemble
		- Move	- Transport
			- Handle
		- Rest	- Store
			- Wait
		- Verify	- Inspect
			- Test
			- Measure
	- Market	- Acquire
		- Sell
		- Distribute
		- Service
Support Oriented	- Install
	- Maintain
	- Set-up
	- Repair
2.	Background SECTION

2.1	Examples

The EA Validate Customer needs as inputs the file of orders (Processable_Orders file) and the file of customers (Customer_Info file). It produces as outputs the updated customer file (New_Customer_Info), the customer order records (Orders), the invalid customer records (Invalid_Customers) and the Customer_status message.

ENTERPRISE ACTIVITY

Header
Type: Identifier: Name: Design Authority:	Administrative/Accounting  EA-21  'Validate Customer' OU-01 'J.P Smith', OC-004 'Accounting'
Body
A. Descriptional Properties  OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION: REQUIRED CAPABILITIES: INPUTS   FUNCTION INPUT:   CONTROL INPUT:   RESOURCE INPUT: OUTPUTS   FUNCTION OUTPUT:   CONTROL OUTPUT:   RESOURCE OUTPUT:   ENDING STATUSES: B. Relational Properties WHERE USED:	O/C-04 'Customer Acceptance' O/C-13 'Credit Limit' DR-1 'Customer Rejection Rule' This enterprise activity is used to check if a customer passing orders is a validate customer in the sense he should not have his credit limit over $ 5000. CS-11 'Validating Customer Capabilities' OV-003 'Processable Orders' OV-004 'Product Info OV-005 'Customer Info' Nil OV-006 'New Customer Info' OV-007 'Order' OV-008 'Product Request' OV-009 'Invalid Customer' Nil  Nil ES(EA-21) = 'Validation Completed': normal termination 'Incomplete Validation': abnormal termination DP-03 'Customer Order Processing'
2.2	Document References (none)

2.3	Open Issues (none)

(*)	Note: Function Output must not be empty (i.e. the activity must produce something).

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Function Input
CIMOSA Technical Baseline

Function Input

B11-2230. Version: 5.2; Last Update: 96.01.27

1.	Technical Section

1.1	Purpose and Scope

Describes the inputs to be processed by the functionality of an Enterprise Activity, and possibly the inputs of a Domain Process or Business Process.

1.2	Terms and Definitions

(1)	Function Input (*) (**):

(a)	at the Requirements Definition Modelling Level is a Building Block Component defined as a set of Object Views which are operated on during the execution of an Enterprise Activity in order to produce the Function Output. Function Input can also apply to Domain Processes and Business Processes.

(b)	consists-of: set-of (Object View (***)).

1.3 Abbreviations and Acronyms (none)

1.4	Description

The Function Input of an Enterprise Activity is a set of Object Views on Enterprise Objects (i.e. external manifestations of input objects) which are operated on by the functionality of that Enterprise Activity. These Object Views can come from the Function Output of one of the Enterprise Activities of the Domain or from the outside, i.e. from another Domain via a Domain Relationship. Enterprise Activities must have a Function Input defined as a set of Object Views. This is mandatory.

At the Particular Level, the functionality part of Domain Processes and Business Processes is also allowed to have a Function Input defined which is made of Object Views of the Information View. This is optional. When it is defined, it represents objects to be processed and required at the beginning of the process. It then becomes Function Input of Enterprise Activities used within this process. A Function Input can consist of either:

-	one occurrence of each Object View instance involved

-	or a flow of occurrences of Object View instances (i.e. a sequence of occurrences of the same type of Object View is received)

An unbounded flow of objects is declared in a Function Input by the use of the optional expression "STREAM OF" before the Object View name. If "STREAM OF" is not used, one occurrence (i.e. the last version) of the Object View is assumed.

We distinguish between two major classes of Object Views -information and physical - as components of Function Input because of their different logistic properties and the need to design different storage systems for them. Physical Object Views represent physical objects of the enterprise which are not made of information only (e.g. raw materials, workpieces, end products, etc.). Information Object Views represent information entities of the enterprise (e.g. documents, forms, files, data, etc.). This distinction provides the CIMOSA modelling approach with a very interesting property since the same integrated model can be used to represent:

-	the flow of information (usually called data flow in other modelling approach); and

-	the flow of materials.

The Object View construct is fully documented in the Information View.

1.5	Description Templates (none)

Function Inputs are described using the Object View template of the Information View.

2.	Background Section

2.1 Examples

Example 1:

Typical Function Input of a Customer Order Processing activity is made of a reference to a customer order, the product file and the customer file. This will be indicated in the Function Input entry of an Enterprise Activity as follows:

FUNCTION INPUT:

- 	OV-003 'Processable Orders'

- 	OV-004 'Product Info'

- 	OV-005 'Customer Info'

where Customer_Order, Product_File and Customer_File are names of Object Views. In this case these Object Views must be described in the Information View of the model.

Example 2:

The Function Input of an on-line Customer Order Processing activity can be made of a flow of Customer_Order (Object Views) processed one by one when they arrive. The input is scanned for new entries as long as the activity is active::

FUNCTION INPUT

- 	OV-003 / STREAM OF 'Processable Order'

2.2	Document References (none)

2.3	Open Issues (none)

(*)	The set of Object View instances, occurrences of which are operated on during the execution of occurrences of the Enterprise Activity instance.

(**)	The set of Object View instances, occurrences of which are required for processing at the beginning of occurrences of the Domain Process or Business Process instance. Can be left undefined in this case.

(***)	Must be defined (even if empty) for Enterprise Activity instances.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Function Output
CIMOSA Technical Baseline

Function Output

B11-2240. Version: 5.2; Last Update: 96.01.27

1.	Technical Section

1.1	Purpose and Scope

Describes the outputs resulting from the execution of the function of an Enterprise Activity, and possibly the end results of Domain Processes and Business Processes.

1.2	Terms and Definitions

(1)	Function Output (*) (**):

(a)	at the Requirements Definition Modelling Level is a Building Block Component defined as a set of Object Views which are produced by an Enterprise Activity as the result of its execution. Function Output can also apply to Domain Processes and Business Processes.

(b)	consists-of: set-of (Object View (***)).

1.3	Abbreviations and Acronyms (none)

1.4	Description

The Function Output of an Enterprise Activity is a set of Object Views produced as a result of the actions performed on its Function Input and using the Control input. Enterprise Activities must produce a Function Output defined as a set of Object Views. This is mandatory. Object Views of the Function Output of an Enterprise Activity can be used in Function Input or Control Input of other Enterprise Activities of the same Domain or of other Domains. At the Particular Level, the functionality part of Domain Processes and Business Processes is also allowed to have Function Output which is made of Object Views. When it is defined, it documents the end result(s) of the processes. This is optional.

A Function Output can consist of either:

-	one occurrence of each Object View instance involved

-	or a flow of occurrences of Object View instances (i.e. a sequence of occurrences of the same type of Object View is produced)

An unbounded flow of objects is declared in a Function Output by the use of the optional expression "STREAM OF" before the Object View name. If "STREAM OF" is not used, one occurrence (i.e. the last version) of the Object View is assumed.

We distinguish between two major classes of Object Views -information and physical - as components of Function Input because of their different logistic properties and the need to design different storage systems for them. Physical Object Views represent physical objects of the enterprise which are not made of information only (e.g. raw materials, workpieces, end products, etc.). Information Object Views represent information entities of the enterprise (e.g. documents, forms, files, data, etc.). This distinction provides the CIMOSA modelling approach with a very interesting property since the same integrated model can be used to represent:

-	the flow of information (usually called data flow in other modelling approach); and

-	the flow of materials.

The Object View construct is fully documented in the Information View.

1.5 Description Template (none)

Function Outputs are described using the Object View template of the Information View.

2.	Background Section

2.1	Examples

Example 1:

Typical Function Output of a Customer Order Processing activity is made of a reference to a customer order, the product file and the customer file. This will be indicated in the Function Output entry of an Enterprise Activity as follows:

FUNCTION OUTPUT:

- 	OV-006 'New Customer Info'

- 	OV-007 'Order'

- 	OV-008 'Product Request'

where Validated_Order, Product_Request and Pending_Customer_ Bill are names of Object Views. In this case these Object Views must be described in the Information View of the model.

Example 2:

The Function Output of an activity producing a list of Procurement_Order(s) (Object Views) one by one can be defined as:

- 	OV-007 / STREAM OF 'Order'

2.2	Document References (none)

2.3	Open Issues (none)

(*)	The set of Object View instances, occurrences of which are produced by occurrences of an Enterprise Activity instance as a result of their execution.

(**)	The set of Object View instances defining the end result(s) of a Domain Process or Business Process instance. Can be left undefined in this case.

(***)	Must be a non empty set of Object View instances for Enterprise Activity instances.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Control Input
CIMOSA Technical Baseline

Control Input

B11-2250. Version: 5.2; Last Update: 96.01.27

1.	Technical Section

1.1	Purpose and Scope

Contains information used to control or to constrain the execution of an Enterprise Activity but not modified by the Enterprise Activity.

1.2	Terms and Definitions

(1)	Control Input (*) (**):

(a)	at the Requirements Definition Modelling Level is a Building Block Component defined as a set of Object Views which will be used to direct (i.e. constrain) or pass run-time information to the operations of an Enterprise Activity but will not be modified by the functionality of the Enterprise Activity. Control Output can also apply to Domain Processes and Business Processes.

(b)	consists-of: set-of (Object View).

1.3 Abbreviations and Acronyms

NC:	Numerical Control

1.4	Description

A Control Input is defined as a set of Object Views related to Enterprise Objects in the Information View. The elements, i.e. Object Views, of the Control Input of a functionality are used to parameterise, i.e. pass run-time data, and constrain the operations of this functionality. They are not modified by the functionality. Object Views of a Control Input can come from Function Output of Enterprise Activities, outside Domains or be associated to Events involved in the triggering of the processes employing the functionality having this Control Input.

In the case of an Enterprise Activity:

Object Views in a Control Input provide information to the Enterprise Activity which is described in the Information View but is not transformed by the operations of the Enterprise Activity (e.g. part identification, manufacturing schedules, NC programs, etc.).

Object Views in a Control Input are in many cases Object Views associated to the Events involved in the triggering of the Domain Process employing the Enterprise Activity. However, they can also be Object Views derived through actions in processing Object Views of Events.

The Control Input may also be interpreted as constraints on the operation, which contain such information as rules, instructions, company policies, e.g. the Enterprise Activity can only be used within certain quantity limits, or allowable scrap rate. Control Input is optional for the functionality part of Domain Processes and Business Processes. If used, it must contain Object Views for Control Input of Enterprise Activities employed by these Domain Processes or Business Processes.

A Control Input can consist of either:

-	one occurrence of each Object View instance involved

-	or a flow of occurrences of Object View instances (i.e. a sequence of occurrences of the same type of Object View is used)

An unbounded flow of objects is declared in a Control Input by the use of the optional expression "STREAM OF" before the Object View name. If "STREAM OF" is not used, one occurrence (i.e. the last version) of the Object View is assumed.

1.5	Description Template (none)

Control Inputs are described using the Object View template of the Information View.

2.	Background Section

2.1 Examples

Example of Control Input:

A machining activity can be constrained by the execution of a given schedule. This schedule is an Object View produced as a Function Output of a scheduling activity and used as Control Input of the machining activity. In the Control Input it is referred to as:

CONTROL INPUT:

-	OV-009 'Schedule'

The Object View OV1 must be defined in the Information View of the model.

2.2	Document References (none)

2.3	Open Issues (none)

(*)	For an Enterprise Activity: the set of Object View instances, occurrences of which will be used to direct or pass information to the operations of occurrences of the Enterprise Activity instance, if any.

(**)	For a Domain Process or Business Process: the set of Object View instances, occurrences of which are used as Control Input of occurrences of Enterprise Activity instances employed by the Domain Process or Business Process instance. Optional.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Control Output
CIMOSA Technical Baseline

Control Output

B11-2260. Version: 4.0; Last Update: 92.08.25

1.	Technical Section

1.1	Purpose and Scope

Provides the set of Events, occurrences of which could be generated by occurrences of an Enterprise Activity or of its employing processes.

1.2	Terms and Definitions

(1)	Control Output (*) (**):

(a)	at the Requirements Definition Modelling Level is a Building Block Component defined as a (possibly empty) set of Events, occurrences of which can be generated by occurrences of an Enterprise Activity. Control Output can also apply to Domain Processes and Business Processes.

(b)	consists-of: set-of (Event).

1.3	Abbreviations and Acronyms (none)

1.4	Description

During its execution an Enterprise Activity can raise Events, which can in turn activate the processing of Domain Processes within the same Domain (endogenous Events) or in different Domains (exogenous Events). The list of instances of such Events is provided by the Control Output of an Enterprise Activity instance.

A Control Output can also be defined for Domain Processes and Business Processes for documentation purpose. This is optional. In the case it is defined, model consistency must be ensured by the following rule:

Consistency Rule: The Control Output of a Domain Process (respect. Business Process) is a set of Event instances which is the union set of Event instances involved in the Control Output of all Enterprise Activity instances employed by the Domain Process (respect. Business Process).

1.5	Description Template (none)

Control Outputs are described as Events using the Event template.

2.	Background Section

2.1	Examples

Let us consider a Machining Monitoring Enterprise Activity. This activity compares the actual machining operations status with the planned schedule. In case of significant deviations the activity can trigger a Domain Process for rescheduling, raising an Event EV-1 called Rescheduling Request. If no other Event can be generated by this activity its Control Input is then denoted by:

CONTROL OUTPUT:

-	EV-03 'Rescheduling Request'

Event EV-03 is then fully defined using the Event template.

2.2	Document References (none)

2.3	Open Issues (none)

(*)	Event instances, occurrences of which can be generated by occurrences of the Enterprise Activity instance having such a Control Output.

(**)	Event instances, occurrences of which can be generated as Control Output of occurrences of Enterprise Activity instances used by the Domain Process or Business Process instance. Optional.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Resource Input
CIMOSA Technical Baseline

Resource Input

B11-2270. Version: 5.2; Last Update: 96.01.27

1.	Technical Section

1.1	Purpose and Scope

Defines resources required for the execution of an Enterprise Activity.

1.2	Terms and Definitions

(1)	Resource Input: at the Requirements Definition Modelling Level is described by the relevant Capability Set of the Resource View. The Resource choice itself is a design task.

1.3	Abbreviations and Acronyms (none)

1.4	Description

The execution of an Enterprise Activity usually requires a given set of Resources providing Capabilities. This is expressed by the Capability Set Construct defined in the Resource View. This enables the statement of requirements independent of the actual resources and defers the selection to a more quantitative modelling state (definition of Alternative Resources and evaluation of choices through simulation). The same applies to Domain Processes and Business Processes.

1.5	Description Template (none)

Resource Inputs are described using the Capability Set template of the Resource View. The Resource Input, supposed to provide the list of necessary Resources for an Enterprise Activity, is left undefined at the Requirements Definition Modelling Level and will be defined at the Design Specification Modelling Level.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Resource Output
CIMOSA Technical Baseline

Resource Output

B11-2280. Version: 5.1; Last Update: 94.07.12

1.	Technical Section

1.1	Purpose and Scope

Provides requirements on the status of Resources as they are returned after the execution of an Enterprise Activity.

1.2	Terms and Definitions

(1)	Resource Output (*) (**): at the Requirements Definition Modelling Level is a Building Block Component defined as a set of textual statements indicating information to be recorded on the usage of the Resources after execution of an Enterprise Activity. Resource Output can also apply to Domain Processes and business Processes.

1.3	Abbreviations and Acronyms (none)

1.4	Description

Resource Output states what information needs to be collected on the usage of Resources during the execution of an Enterprise Activity. They are defined by textual statements. Resource Output essentially applies to Enterprise Activities. However it can also be defined for the functionality part of Business Processes and Domain Processes which are supposed to use the Resources used by their Enterprise Activities for their full duration (***). In the Enterprise Operations Environment after the execution of an Enterprise Activity, the Resources are returned to a resource pool for possible further use. Therefore it is necessary to convey the status of the Resource (ready for use, damaged, out order, etc.) as it is returned to the pool. The execution of Enterprise Activities may cause the full or partial consumption of the Resource Input. The Resource Output is used to convey information about this usage. The Resource Output indicates how much of the resource has been used. Resource Management can use this information to determine how much of the resource is available for future use. Exact specification of Resource Output will be defined at the Design Specification Modelling Level, after the Resources have been specified in the Resource View.

1.5	Description Template (none)

Resource Outputs are described using the Capability Set template of the Resource View.

2.	Background Section

2.1	Examples

For a machining activity, one may wish to record the following information for further machine and tool maintenance as the Resource Output:

RESOURCE OUTPUT:

- record actual machining time

- record tool use for each tool used

- record tool change times

2.2	Document References (none)

2.3	Open Issues (none)

(*)	The information to be recorded on the usage of the resource after execution of occurrences of the Enterprise Activity instance.

(**)	The information to be recorded on the usage of the resource after execution of occurrences of Enterprise Activity instances of the Domain Process or Business Process instance. Optional.

(***)	Note: Due to the fact that at the Requirements Definition Modelling Level only requirements are defined, Resource Output is only defined under special conditions, namely when a business requirement on this specific information regarding resource usage must be provided to be used elsewhere in the model, and especially for resource management.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Ending Status
CIMOSA Technical Baseline

Ending Status

B11-2290. Version: 1.2; Last Update: 96.01.27

1.	Technical Section

1.1	Purpose and Scope

Provides the set of ending values which could be generated by occurrences of an Enterprise Activity or of its employing Business Processes.

1.2	Terms and Definitions

(1)	Ending Status:

(a)	of an Enterprise Activity (respectively, a Business Process) is a value describing one of the possible termination states of the Enterprise Activity (respectively, the Business Process), and required for further processing in the set of Behavioural Rules in which this Enterprise Activity (respectively, this Business Process) is involved.

(b)	consists-of: set-of (0-argument predicate) (*).

1.3	Abbreviations and Acronyms

IIS:	Integrating Infrastructure

BP:	Business Process

EA:	Entrprise Activity

ES:	Ending Status

OV:	Object View

1.4	Description

When occurrences of Enterprise Activities are executed in the Enterprise Operation Environment, they deliver a completion status called Ending Status summarising how the Enterprise Activity occurrence was performed. Its value is a post-mortem intrinsic property of the occurrence of the Enterprise Activity. The status contains only information characterising the termination state reached by a given occurrence of the Enterprise Activity.  The value of an Ending Status is not contained in any Object View of the particular model. It is captured as a value and used by the service of the Business Entity of the IIS. It is used as a dynamic input to Behavioural Rules in order to select the next action (Business Process or Enterprise Activity) to be executed in a Behavioural Rule set.

Definition: Ending Status values are defined as 0-argument predicates at the Requirements Definition Modelling Level (**).

Values of Ending Statuses are unrestricted in number. There may be as many values as required (e.g. 1, 2, 20 or 200) to represent the various termination conditions. However it can be verified that any Enterprise Activity can always terminate by one of the following ending states:

1.	FINISHED for normal, planned, termination

2.	TERMINATED for termination by external intervention (could be the Integrating Infrastructure of CIMOSA)

3.	ABANDONED for internal termination by the activity itself

These values can be used as values of Ending Statuses as well as their aliases (e.g. 'OK', 'done' for 'FINISHED'). Furthermore, an Ending Status can also be a function of components of the Function Output of the Enterprise Activity.

For instance let us consider the situation of Figure B11-2290/1 in which an Enterprise Activity EA-1 receives Object Views OV-1, OV-2 and OV-3 as Function Input and can or cannot produce Object Views OV-11 and OV-12 as Function Output. An Ending Status value can be defined for each of the situations indicated.

To summarise, most generic Ending Status values are 'FINISHED', 'ABANDONED' and 'TERMINATED'. In each case, more precise, user-defined, Ending Status values can be declared (e.g. 'FINISHED WITH PRIORITY CLASS 2', 'OK AND LENGTH > 100', 'ABANDONED AND OV-22 NOT PRODUCED', etc.).

Similarly, the same concept can be defined for Business Processes, except that the Ending Status of a Business Process must be a logical function of Ending Statuses of its employed Enterprise Activities. Four basic kinds of situation can be encountered:

-	Business Process finishing by one Enterprise Activity (the Ending Status values of the Business Process are the Ending Status values of the Enterprise Activity)

-	Business Process finishing by n (n>1) exclusive Enterprise Activities (the set of Ending Status values of the Business Process is the union set of the Ending Status values of each Enterprise Activity)

-	Business Process finishing by n (n>1) non-exclusive Enterprise Activities (the set of Ending Status values of the Business Process is the factorial combination of the Ending Status values of all Enterprise Activities). This kind of situation should be avoided as much as possible.

Ending State	Object View	produced
	Object View	Object View
	OV-11	OV-12
Finished	yes	yes
	yes	no
	no	yes
	no	no
Terminated	yes	yes
	yes	no
	no	yes
	no	no
Abandoned	yes	no
	no	yes
	no	no
Figure B11-2290/1: Enterprise Activity and its possible Ending Statuses

-	Business Process finishing by a rendezvous of n (n>1) Enterprise Activities (the set of all possible Ending Status values of the Business Process is the logical conjunction of values (AND operator) in all elements of the Cartesian product of the sets of Ending Status values of these Enterprise Activities).

All other types of situations can be defined using these principles recursively, i.e. replacing a term 'Enterprise Activity' by 'Business Process'. The Business User must realise that this is subject to combinatorial explosion. To limit this, it is however possible to define an Ending Status value of the Business Process as made of a set of logical combinations of Ending Status values of employed Enterprise Activities (i.e. to aggregate Ending Statuses).

For instance, if Business Process BP-1 finishes by Enterprise Activity EA-1, the Ending Status of BP-1 is the Ending Status of EA-1. If Business Process BP-1 finishes by either Enterprise Activity EA-1 or Enterprise Activity EA-2, then the Ending Status of BP-1 is given by (Ending Status of EA-1 OR Ending Status of EA-2). If Business Process BP-1 finishes by a rendezvous of EA-1 and EA-2, then the Ending Status of BP-1 is given by (Ending Status of EA-1 AND Ending Status of EA-2). In all these cases the actual value can only be known at run-time when the FINISH statement of the set of Behavioural Rule of the Business Process is reached.

Ending Statuses could be defined for Domain Processes but are not required since they are not used anywhere in the CIMOSA model.

Important Remark: The concept of Ending Status is fundamental in achieving one of the major CIMOSA principles: isolation between control and function). Indeed, Ending Statuses are generated by functions as synthesised information and then used to direct the flow of control.

In CIMOSA Ending Status values are user-defined values expressed as 0-argument predicates. Future versions of CIMOSA might allow the definition of Ending Statuses as first-order logic predicates to handle variables which could be Information Elements of Object Views of the Function Input and Control Input of the Enterprise Activity.

The values of Ending Statuses are generated within the Enterprise Activities when these complete correctly or can be forced by the execution control environment (IIS) otherwise.

1.5	Description Template (none)

2.	Background Section

2.1	Examples

Let us consider a Machining Monitoring Enterprise Activity. One of its input values in its Control Input is assumed to be the requested quantity (Qrequested) of parts. One of its output values in its Function Output can be the quantity produced (Qproduced). Therefore, the two following expressions

- 	Qproduced < Qrequested

- 	Qproduced >= Qrequested

defined as 0-argument predicates can be used for Ending Status values in the Behavioural Rules of Machining Monitoring as follows:

ON (ES(Machining) = 'TERMINATED') DO BP-AA

ON (ES(Machining) = 'Qproduced < Qrequested') DO BP-XX

ON (ES(Machining) = 'Qproduced >= Qrequested') DO BP-YY

where ES is a function returning the Ending Status of a functionality and BP-AA, BP-XX and BP-YY are fictive examples of Business Processes.

2.2	Document References (none)

2.3	Open Issues

1.	The use of variables in Ending Statuses (defined as n-array predicates) is being investigated. However, this may destroy (or at least pollute) the basic CIMOSA principle of separation of function and control.

(*)	Values describing the termination states (or conditions) of occurrences of an Enterprise Activity instance (respectively, Business Process instance).

(**)	Note: The list of all possible Ending Status values for each Enterprise Activity must therefore be established in a CIMOSA model, if the behaviour of the enterprise is to be fully defined.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Event
CIMOSA Technical Baseline

Event

B11-2300. Version: 4.3; Last Update: 96.01.28

1.	TECHNICAL SECTION

1.1	Purpose and Scope

Defines solicited or unsolicited happenings of the enterprise involving a change in the state of the enterprise.

1.2	Terms and Definitions

(1)	Event: is either a (solicited or unsolicited) real-world happening, timer or request to do something in the enterprise or in its environment. It can carry information (defined as an Object View). It is used to trigger the execution of one or more Domain Processes (and hence indirectly activates an employed Business Process/Enterprise Activity) by initiating the processing of their associated set of Behavioural Rules. It may also be used to condition the flow of control of a Business Process within a Domain Process.

1.3	Abbreviations and Acronyms

CAEE:	Computer-Aided Enterprise Engineering

PCB:	Printed Circuit Board

RDM: 	Requirements Definition Model

DP:	Domain Process

EV:	Event

OC:	Organisation Cell

OU:	Organisation Unit

OV:	Object View

1.4	Description

1.4.1	Introduction

Enterprise Events are facts associated with requests (solicited happenings) or unsolicited real-world happenings (inside or outside the enterprise) or timers, which require certain action. They characterise a change in the state of the enterprise. Occurrences of Events are used to activate occurrences of Domain Processes and in the processing of Behavioural Rules. We distinguish:

-	Timers (i.e. clock times) when certain enterprise actions have to be performed upon specified times (e.g. time = 5:00 p.m.)

-	Requests or orders (i.e. solicited happenings) such as arrival of an order, a customer request, a management order, etc.

-	Unsolicited happenings such as a signal indicating a machine failure, an alarm, unexpected order, etc..

Occurrences of Events are mainly used to directly trigger the execution of occurrences of Domain Processes. Occurrences of Events never directly trigger occurrences of Business Processes or Enterprise Activities, but can also contribute to activate the execution of occurrences of Business Processes and Enterprise Activities. In other words, Events are allowed to be used in the triggering condition of Business Processes or Enterprise Activities. They may occur and be processed either in the same domain or in different domains. In the latter case events are crossing the boundary of the Domain (e.g. the receipt of a customer order) and be involved in Domain Relationships.

Events can carry information but they are not Object Views. The information carried by the Event is defined in terms of an Object View. This information will be passed to the Enterprise Activities called by the set of Behavioural Rules of the Domain Process at run-time. The connection is made via the Control Input of the Enterprise Activities. This information can provide run-time data (e.g. part number, number of parts to be machined, etc.). The sources of Events in a CIMOSA model are limited to:

-	Resources, and especially Functional Entities (e.g. machine failure, error detection, management orders, etc.)

-	Enterprise Activities via their Control Output (e.g. request to do something, list of orders, error detection, etc.)

-	Non-CIMOSA Domains for external solicitations (e.g. management orders, customer requests, etc.)

Occurrences of Events are always handled by the CIMOSA Integrating Infrastructure (via the services of the Presentation Entity). They are used to trigger (unsolicited actions, requests, timers) or to stop (requests) Domain Processes (and their subservient functionalities).

Property: An Event can be used to trigger several Domain Processes within an enterprise. A Domain Process can be triggered by means of several Events. In other words, there is no one-to-one mapping between Events and Domain Processes.

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Event instances of all types are described by the following template:

EVENT

Header
Type Identifier: Name: Design Authority:	[relevant category - select from list <name>] [EV-<unique identifier>] [name of the Event instance in the form: <adjective > <noun>      <noun>: relates to the object causing the Event       <adjective>: qualifying attribute]  [<identifier> / <name> of Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance]
Body
A. Descriptional Properties: DESCRIPTION: RELATED OBJECT VIEW: B. Relational Properties: GENERATED BY: TRIGGERS:	[textual description of the instance; optional] ['NIL' or <identifier> / <name> of the Object View instance containing the information content of the Event instance]  [list of <identifier> / <name> of Domain or Enterprise Activity instances, occurrences of which can generate occurrences of this Event instance. Can be left undefined at the RDM Level] [list of <identifier> / <name> of Domain Process instances, occurrences of which can be triggered by means of occurrences of this Event instance. Automatically maintained by the CAEE tool]
1.6	List of Types

These types are only illustrative examples of families of Event Types that may eventually exist.  They have not been approved as official CIMOSA Building Block Types so far.

Category 0	Category 1
- Timed Event
- Order	- verbal
	- confirmed
- Happening	- planned
	- unplanned
	- deterministic
	- non-deterministic
- Signal
2.	Background Section

2.1	Examples

Example 1: The purpose of this example is to show the definition of an Event using the template.

EVENT

Header
Type: Identifier: Name: Design Authority:	Management order/Change request EV-04 'PCB Change Request' OU-01: 'M. Synders', OC-002 'Product Engineering'
Body
A. Descriptional Properties: DESCRIPTION: RELATED OBJECT VIEW: B. Relational Properties: GENERATED BY:  TRIGGERS:	Modification of specification at request of customer. This leads to a Change Request. OV-010 'PCB-data DP-04 'Prototypes Manufacturing' DP-05 'PCB Design'
2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Declarative Rule
CIMOSA Technical Baseline

Declarative Rule

B11-2500. Version: 4.4; Last Update: 96.01.28

1.	Technical Section

1.1	Purpose and Scope

Defines the enterprise strategies for the control of the enterprise decision-making process in the form of constraints and/or combinations of objectives and constraints together with the conditions under which they apply.

1.2	Terms and Definitions

(1)	Declarative Rule: is a set of objectives and constraints combined with a set of conditions for their applicability (i.e. a Declarative Rule allows objectives and constraints to be combined and applied under conditions). Declarative Rules can be imposed within Domains on Domain Processes, Business Processes and Enterprise Activity(ies).

1.3 Abbreviations and Acronyms

CAEE:	Computer-Aided Engineering Environment

DP:	Domain Process

DR:	Declarative Rule

EA:	Enterprise Activity

OC:	Organisation Cell

O/C:	Objective/Constraint

OU:	Organisation Unit

1.4	Description

1.4.1	Generalities

Declarative Rules can be used to combine objectives and constraints together with conditions using logical (i.e. Boolean) expressions to express business rules (i.e. a part of the business know-how). A number of objectives and constraints of different natures may be identified during the creation of a Particular Requirements Definition Model. These may concern, for example, characteristics or structures that the Particular Model may or may not exhibit/include, implementation constraints (which apply to the Enterprise Engineering Process for the Particular Requirements Definition Model), or run-time constraints on the operation of selected functions of the enterprise.

Declarative Rules are (complex) combinations of business objectives and constraints applicable to the execution of Domain Processes, as well as conditions on Business Processes and/or Enterprise Activities. They either give rise to specific structures of Enterprise Activities (as defined at the Design Specification Modelling Level) or constrain the run-time execution of activities and are implemented in the form of pre- and post-conditions (as specified at the Design Specification and the Implementation Description Modelling Levels).

The Declarative Rule is the construct provided to express combination of these objectives and constraints, the conditions under which they will be applied, as well as their validity. They represent imposed business constraints. Objectives and Constraints are constructs involved in the specification of Declarative Rules. They have been defined as general constructs of the Function View. Declarative Rules are expressed by a set of Objectives and Constraints linked under a set of conditions. The objectives and constraints are related to a specific part of the System Life Cycle. They can be:

-	Design Objectives/Constraints, that apply to the System Design phase

-	Implementation Objectives/Constraints, that apply to the System Build and Release phase

-	Operations Objectives/Constraints that apply to the System Operation phase

-	Modification Objectives/Constraints that apply to the System Change phase

Declarative Rules which constrain in some way the run-time operations of one or more Enterprise Activities can be taken into account at run-time. Such Declarative Rules may, for instance, direct a specified Enterprise Activity (whose implementation allows for designing with various kinds of standard components) to select only components from one vendor when designing a Printed Circuit Board. Declarative Rules can be made of several rule elements. They are defined by one or several 'IF (set of conditions) THEN (rule element) APPLY' statements.

1.5	Description Templates

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Declarative Rule instances of all types are described by the following template:

DECLARATIVE RULE

Header
Type: Identifier: Name: Design Authority:	[relevant category - select from list <name>] [DR-<Unique Identifier>] [name of Declarative Rule in the form: <adjective> <noun> <noun>: relates to the scope of the rule <adjective>: relates to the nature of the rule] [<identifier> / <name> of Organisation Unit and/or Organisation Cell with the authority to design/maintain this particular instance]
Body
A. Descriptional Properties: DESCRIPTION: SET OF CONDITIONS: SET OF RULE ELEMENTS: B. Relational Properties: IMPOSED ON: COMPRISES:   OBJECTIVES:   CONSTRAINTS:	[short textual description of the Declarative Rule instance] [list of conditions in the form: <identifier> ":" <condition> where <identifier> is user-defined (e.g. C1) and <condition> is made of Objective/Constraint identifiers of objectives and constraints involved in the rule connected by AND, OR and NOT operators and parentheses, if required] [list of IF THEN Clauses of the Behavioural Rule instance in the form: IF (set of conditions) THEN (list of <identifier> of Objective/Constraint separated by comma) APPLY] [list of <identifier> / <name> of Domain Process and/or Business Process and/or Enterprise Activity instances on which this rule is imposed] [list of <identifier> / <name> of Objective/Constraint instances representing objectives]  [list of <identifier> / <name> of Objective/Constraint instances representing applicable constraints]
1.6	List of Types

This list provides illustrative examples rather than real index of types.

Category 0	Category 1
- Design	- Conceptual Design
	- Detailed Design
	- Simulation
- Implementation	- Description
	- Installation
	- Test
- Operational	- Management Support
- Modification
2.	Background Section

2.1 Examples

This example provides a Declarative Rule constraining quality requirements which can be applied for a parts manufacturing Business Process which can serve regular customers or the army.

DECLARATIVE RULE

Header
Type: Identifier: Name: Design Authority:	Parts Manufacturing DR-2 Quality Manufacturing Rule OU-02 'J.J. Smith', OC-002 'Product Engineering'
Body
A. Descriptional Properties: DESCRIPTION: SET OF CONDITIONS: SET OF RULE ELEMENTS: B. Relational Properties: IMPOSED ON: COMPRISES:   OBJECTIVES:   CONSTRAINTS:	Selection of suppliers according to quality target requirements - C1: O/C-20 AND O/C-50 - C2: O/C-21 AND O/C-50 - C3: O/C-22 AND O/C-50 - IF C1 THEN O/C-70, O/C-71 APPLY - IF C2 THEN O/C-70, O/C-71 APPLY - IF C3 THEN O/C-71 APPLY DP-06 'Product Quality Control' EA-02 'Control Quality' - O/C-20 'Scrap Rate' <= 10% - O/C-21 'Scrap Rate' <=  5% - O/C-22 'Scrap Rate' <=  2% - O/C-50 'Customer Type' = Defence - O/C-51 'Customer Type' = Regular - O/C-70 'Supplier Name' = "ABC" - O/C-71 'Supplier Name' = "XYZ"
2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Domain Relationship
CIMOSA Technical Baseline

Domain Relationship

B11-2600. Version: 4.2; Last Update: 96.01.28

1.	Technical Section

1.1	Purpose and Scope

Defines boundaries and relationships between the Domain being established and the Domains which have exchange with it.

1.2	Terms and Definitions

(1)	Domain Relationship:

(a)	is a construct used to define the interactions between two related Domains.

(b)	indicates Events and Object Views which can be exchanged by two Domains, specifying which are going in and which are going out of the Domains.

(2)	Domain Boundary: of a Domain is defined by the set of Domain Relationships in which the Domain is involved.

1.3	Abbreviations and Acronyms

DM:	Domain

EV:	Event

OC:	Organisation Cell

OU:	Organisation Unit

OV:	Object View

1.4	Description

1.4.1	Introduction

For each particular Domain, a Domain boundary has to be defined which specifies the Domain Relationships between this Domain and other Domains (within or outside the enterprise, irrespective if they are CIMOSA compliant or not). A Domain Relationship always exists when a pair of Domains have some interactions in the form of exchange of occurrences of Object Views or Events. A Domain Relationship can be seen as an exchange channel between two adjacent Domains. A Domain Relationship is defined in terms of occurrences of Object Views and Events sent/received by a Domain to/from another Domain.

Whenever an occurrence (or a set of occurrences, whatever is more appropriate) of an Object View (i.e.  one or more real-world objects) is received from another Domain, which is specified in the Domain Relationship, an Event occurs. However, Events can cross Domain boundaries without any reference to occurrences of Object Views (e.g. verbal management orders, temporal events, alarms). It may even happen that several Events relate to the same Object View for a given Domain Relationship (e.g. Events related to different statuses of the same object of a given Object View which goes several times through the same Domain Relationship). The Domain Relationship must indicate the (estimated) frequency of interactions for Object Views and Events.

1.4.2	General Constraints

-	The instantiation of all Domain Relationships is constrained by the defined Domain Relationship Instantiation Rules.

-	A Domain Relationship is always defined between only two adjacent Domains (called Domain 1 and Domain 2).

-	Only occurrences of Events and Object Views are allowed to cross Domain boundaries.

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Domain Relationship instances of all types are described by the following template (*) (**) (***):

DOMAIN RELATIONSHIP

Header
Type: Identifier: Name: Design Authority:	[relevant category - select from list] [RL-<unique identifier>] [name of the Domain Relationship] [<identifier> / <name> of Organisation Unit and/or Organisation Cell with authority to design/maintain this Domain Relationship instance]
Body
A. Descriptional Properties: DESCRIPTION: DOMAIN 1 NAME: DOMAIN 2 NAME: INVOLVED OBJECT VIEWS:    Identifier:    Name:    FROM:    TO:    FREQUENCY: INVOLVED EVENTS:    Identifier:    Name:    FROM:    TO:    FREQUENCY: B. Relational Properties:	[short textual description of the Domain Relationship instance] [name of first Domain instance involved in the Domain Relationship instance]  [name of second Domain instance involved in the Domain Relationship instance. Must be different from DOMAIN 1 NAME] ['NIL' or list of involved Object View instances in tabular form containing: [the Object View instance identifier] [the Object View instance name] [the Domain instance from which occurrences of the Object View instance are sent (either DOMAIN 1 NAME or DOMAIN 2 NAME] [the Domain instance to which occurrences of the Object View instance are sent (either DOMAIN 1 NAME or DOMAIN 2 NAME but not the one in the FROM entry)] [the frequency of exchange of Object View occurrences] ['NIL' or list of involved Event instances in tabular form containing: [the Event instance identifier]  [the Event name] [the Domain instance from which occurrences of the Event instance are sent (either DOMAIN 1 NAME or DOMAIN 2 NAME)] [the Domain instance to which occurrences of the Event instance are sent (either DOMAIN 1 NAME or DOMAIN 2 NAME but not the one in the FROM entry)] [the frequency of exchange of Event occurrences]]
2.	Background Section

2.1	Examples

The following example is extracted for the Aerospatiale Case Study: "Flexible Manufacturing Shop"

DOMAIN RELATIONSHIP

Header
Type: Identifier: Name: Design Authority:	Operational/Manufacturing  RL-03 'Order Release' OC-003 'Production Control'
Body
A. Descriptional Properties: DESCRIPTION: DOMAIN 1 NAME:  DOMAIN 2 NAME: INVOLVED OBJECT VIEWS:    Identifier:    Name:    FROM:    TO:    FREQUENCY:    Identifier:    Name:    FROM:    TO:    FREQUENCY: INVOLVED EVENTS:    Identifier:    Name:    FROM:    TO:    FREQUENCY:  B. Relational Properties:	Through this relationship the Flexible Manufacturing Shop domain receives information issued by PRODUCTION CONTROL in order to update the Shop Production scenario by adding new Manufacturing Orders and/or modifying existing ones. DM-02 'Production Control' DM-01 'Flexible Manufacturing Shop' OV-011 'Manufacturing Order' DM-02 'Production Control' 'Flexible Manufacturing Shop' 20/month OV-012 'Order Acknowledgement' DM-01 'Flexible Manufacturing Shop' 'Production Control' 20/month EV-05 'Manufacturing Order Release' DM-02 'Production Control' DM-01 'Flexible Manufacturing Shop' 20/month
2.2	Document References (none)

2.3	Open Issues (none)

(*)	Note 1: Domains involved in the Domain Relationship can be internal or external to the Enterprise, but must be different.

(**)	Note 2: Domains involved in the Domain Relationship can be CIMOSA compliant Domains or non-CIMOSA compliant Domains.

(***)	Note 3: Occurrences of the same Object View can be exchanged in both directions by the two Domains. In this case the Object View is described in both directions.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Domain Process
CIMOSA Technical Baseline

Domain Process

B11-2700. Version: 4.3; Last Update: 96.01.28

1.	Technical Section

1.1	Purpose and Scope

Defines the sequence of functionalities which represents the business procedures (i.e. behaviour) in a Domain that must be followed to achieve the desired business objectives or end result.

1.2	Terms and Definitions

(1)	Domain Process:

(a)	is a construct triggered by means of at least one Event and nothing else than Events and producing defined end results (Function Output). It encapsulates a well-defined set of enterprise functionalities and behaviour (i.e. Enterprise Activity(ies), Business Processes, Behavioural Rules) to realise clearly defined objectives under given constraints (Objectives/Constraints).

(b)	receives input from and/or provides output to other Domain Processes. It is only used by one Domain, i.e. it is not used either by any other Domain or a Business Process, and therefore is at the top of a functional decomposition hierarchy.

1.3	Abbreviations and Acronyms

BP:	Business Process

DM:	Domain

DP:	Domain Process

DR:	Declarative Rule

EV:	Event

O/C:	Objective/Constraint

OC:	Organisation Cell

OV:	Object View

1.4	Description

1.4.1	General Description

For each particular CIMOSA Domain of an Enterprise, a non-empty set of Domain Processes is defined. A Domain Process is defined by a hierarchy of Business Processes and Enterprise Activities achieving all or part of the major goals of the enterprise. Domain Processes are triggered by means of nothing but Events and receive/use/create Object Views of Enterprise Objects. (Enterprise Objects and Object Views are constructs of the Information View). A Domain Process fulfils one or more Domain Objectives, and vice versa, a Domain Objective may be achieved by one or more Domain Processes. Domain Processes comply with imposed Domain Constraints and Declarative Rules.

-	A Domain Process must be directly triggered by means of at least one Event and by nothing else than Events.

-	The Domain Process objectives and constraints are directly derived from the Domain Objectives and Domain Constraints, and can themselves be further broken down into sub-objectives and sub-constraints for the Business Processes and Enterprise Activities employed by the Domain Process.

-	The objectives and constraints related to the Domain Process can be involved in some Declarative Rules.

-	In the case it needs to be defined, the Function Input of the Domain Process is made of a set of objects (defined as Object Views) received from other Domains when the Domain Process starts. Similarly, the Function Output provided to other Domains by the Domain Process is a set of objects (defined as Object Views) describing the result(s) or outputs of the process.

Property 1: Within a Domain, there must be at least one Domain Process triggered by means of at least one exogenous Event. (This property ensures that Domains cannot live in a closed world).

Domain Processes are independent of one another and are not linked by a Behavioural Rule to any other Domain Processes (of the Domain or any other Domain) by definition. They are at the root of function decomposition hierarchies of the Function View of the Domain. They behave like stand-alone dynamic objects which have a structure (defining their state) and a behaviour (which describes how they react to external stimuli, i.e. Events). However, Domain Processes can interact with one another in two different ways:

-	by sending Events to one another via the Control Output of their internal Enterprise Activities;

-	by exchanging data and information, which can be used for synchronisation purposes (synchronous or asynchronous modes including producer/consumer mode and request/acknowledgement mode), via the Object Views of the Function Input, Control Input and Function Output of their Enterprise Activities.

The prime purpose of a Domain Process is to encapsulate a consistent set of required functionalities together with the associated behaviour (or flow of control) in order to fulfil some Domain Objectives under Domain Constraints. It must start with the occurrence of one or several well-identified Events and will end up with a well-defined result (i.e. an Object View defined as part of the Function Output). Thus, definition of the starting conditions and end results are of prime importance in designing well-structured Domain Processes of a particular Domain, i.e. full processes.

Finally, a Domain, but also by extension a full Enterprise, can be seen from the CIMOSA functional point of view as made of a countable set of Domain Processes interacting in a distributed environment by the exchange of Events and Object Views (i.e. physical objects and information objects).

1.4.2	Triggering Conditions of Domain Processes

In the Enterprise Operation Environment an occurrence of a Domain Process can be triggered by (see Figure B11-2700/1):

-	an occurrence of an Event (e.g. Event 1)

-	an occurrence of several potential Events (e.g. EV-1 OR EV-2)

-	a triggering condition made of a logical combination of occurren-ces of several Events (AND/OR conditions e.g., (EV-1 AND EV-3)

The triggering conditions for a class of similar Domain Processes are explicitly defined by the triggering rules of the set of Behavioural Rules attached to the Domain Process instance. (See Formal Reference Base item B11-2710). The situation depicted by Figure B11-2700/1 is therefore possible when occurrences of Events (EV-1, EV-2 and EV-3 are used to trigger occurrences of Domain Process DP-1; DP-1 has three different Event entry points for the three events (*)).

Figure B11-2700/1: Triggering Conditions of a Domain Process

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Domain Process instances of all types are described by means of the following template.

DOMAIN PROCESS

Header
Type: Identifier: Name: Design Authority:	[relevant category - select from list <name>] [DP-<Unique Identifier>] [name of Domain Process instance in the form: <adjective> <noun>       <adjective>: qualifying the Domain Process instance       <noun>: related to the scope of the Domain Process] [<identifier> / <name> of Organisation Unit and/or Organisation Cell with the authority to design/maintain this particular instance]
Body
A. Descriptional Properties OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION: INPUTS    FUNCTION INPUT:    CONTROL INPUT:    RESOURCE INPUT: OUTPUTS    FUNCTION OUTPUT:    CONTROL OUTPUT:    RESOURCE OUTPUT: BEHAVIOURAL RULES: Graphical Representation: B. Relational Properties WHERE USED: COMPRISES: EVENTS:	[non-empty list of <identifier> / <name> of Objective/Constraint defining objectives which must be fulfilled by the Domain Process instance;] ['NIL' or list of <identifier> / <name> of Objective/Constraint defining constraints applicable to this Domain Process instance;] ['NIL' or list of <identifier> / <name> of Declarative Rule instances applicable to this Domain Process instance;] [textual description of the tasks performed by this Domain Process; optional] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Object View instances, occurrences of which are processed by activities of this process;] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Object View instances, occurrences of which are used but not processed by activities of this process;] [must be left undefined at this modelling level] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Object View instances, occurrences of which are produced by activities of this process;] ['NIL' or list of <identifier> / <name> of Event instances, occurrences of which could be generated during the course of occurrences of this Domain Process instance;] ['NIL' or list of <identifier> / <name> of Object Views indicating requirements on data collection on resource usage;] [set of formal rules in the form:- When "relevant Business Processes/ Enterprise Activities end and triggering condition becomes true", then do "trigger one or more Business Processes/Enterprise Activities". [optional graphical representation of the Behavioural Rules] Each rule is syntactically defined in the following form: WHEN (<condition>) DO <action> where <condition> defines the triggering condition and <action>  defines the enterprise function to be executed next. The full syntax  is provided in item B11-2710 of the Formal Reference Base and  called Behavioural Rule. [<identifier> / <name> of domain that employs this Domain Process instance. Can be left undefined for partial instances only] [non-empty list of <identifier> / <name> of all next lower level enterprise functions (Business Process or Enterprise Activity instances) that are employed by this Domain Process instance. Can be left undefined for partial instances only] [non-empty list of <identifier> / <name> of Event instances, occurrences of which are involved in the triggering conditions of this Domain Process instance or used within the Domain Process instance]
Remark: By using the optional clause 'STREAM OF', Function Input, Function Output and Control Input can be defined as a stream of Object Views (several occurrences are received in sequence) or as one occurrence of each Object View type indicated.

2.	Background Section

2.1	Examples

DOMAIN PROCESS

Header
Type: Identifier: Name: Design Authority:	Manufacturing Operation/Batch Oriented DP-5 'Gearbox Assembly' OC-001 'Manufacturing Engineering'
Body
A. Descriptional Properties OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION: INPUTS    FUNCTION INPUT:    CONTROL INPUT:    RESOURCE INPUT: OUTPUTS    FUNCTION OUTPUT:    CONTROL OUTPUT:    RESOURCE OUTPUT: BEHAVIOURAL RULES: Graphical Representation: B. Relational Properties WHERE USED: COMPRISES: EVENTS:	O/C-90 'Grant Production Plan at Gearbox Assembly Level O/C-91 'Constraint of Resources and Cost DR-90 'Balance Gearbox Assembly Line between Push and Pull Concept DP-5-'Gearbox Assembly' models the assembly area for gearbox  production consisting of the technological production system and the  production management system. OV-090 'Part' (Purchased parts, components and Sub-assemblies) OV-091 'Status information - old' Undefined at this level OV-092 'Gearbox' (Finished product) OV-093 'Manufacturing Order' (pull) OV-094 'Status information - new' NIL WHEN (START WITH Event EV-44 'Gearbox Assembly Order') DO BP-5.1 & BP-5.2 & BP-5.3 & BP-5.4 & BP-5.5 WHEN (ES(BP-5.1)= 'Case Completed') AND (ES(BP-5.2)= 'Differential Completed') AND (ES(BP-5.3)= 'MShaft Completed') AND (ES(BP-5.4)= 'AShaft Completed') AND (ES(BP-5.5)= 'Kit Completed')  DO BP-5.6 WHEN (ES(BP-5.6)= 'Final Assembly Completed') DO FINISH WHEN (ES(BP-5.x)= 'not Completed') DO 'Exception Handling' (*issue Event-45 *) Optional (see figure B11-2700/2)  DM-1 'Gearbox Production' BP-5.1 'Case, Produce by Line' BP-5.4 'AShaft, Produce by Line BP-5.2 'Diff, Produce by Line' BP-5.5 'Kit, Produce by Line BP-5.3 'Mshaft, Produce by Line' BP-5.6 'Gearbox Final Assembly' EV-44 'Order' from DP-4 'Component Storage' EV-45 'Order' to DP-6 'Deliver Product' EV-25 'Request for 'Exception Handling'
Figure B11-2700/2: Graphical Representation

2.2	Document References (none)

2.3	Open Issues (none)

(*)	Note: A OR condition in the triggering condition of a Domain Process is always defined by separate exclusive rules, one for each expression of the OR condition.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Behavioural Rule
CIMOSA Technical Baseline

Behavioural Rule (*)

B11-2710. Version: 4.2; Last Update: 96.01.28

1.	Technical Section

1.1	Purpose and Scope

Defines a set of Behavioural Rules which are used to represent the flow of control associated to Domain Processes and Business Processes.

1.2	Terms and Definitions

(1)	Behavioural Rule: is a Building Block Component which describes the desired action(s) to be taken in the flow of control of a Domain Process or Business Process.

(2)	a set of Behavioural Rules defines the flow of control of a Domain Process or Business Process by defining selection criteria for executing the next step in a process from its start until its completion. The following set of condition-action rules has been defined:

-	process triggering

-	forced

-	conditional

-	spawning

-	rendezvous

-	looping

-	completion

-	run-time choice

-	unordered set

1.3	Abbreviations and Acronyms

IIS:	Integrating Infrastructure

ES:	Ending Status

1.4	Description

1.4.1	Introduction

Behavioural Rules are used to define the behaviour of the enterprise. They are the 'verbs' used to describe the decisional logic required to determine, under operational conditions, the sequence of Business Processes and/or Enterprise Activities required in order to perform the general tasks of Domain/Business Processes and the behaviour required from the cluster of Enterprise Activities. There are different types of Behavioural Rules which allow, for example, the conditional continuation of Business Processes, the selection of a particular continuation path depending on dynamically established conditions, and the paralleling/synchronisation of Enterprise Activities and Business Processes.

The Behavioural Rule is a formal statement of the intended flow of action between the internal components of a Business Process. The actual flow of action is dependent upon conditions based on the Ending Status of each proceeding Enterprise Activity which supplies decisional criteria for selecting the next Business Process/Enterprise Activity to be triggered. The formal statement has the form:

-	When "relevant Business Processes/Enterprise Activities end and triggering condition becomes true", then

-	Do "trigger one or more Business Processes/Enterprise Activities" (*Event-nn, Event-nm, ... *)" (**).

The basic formal statement can be repeated within one Behavioural Rule set (in effect a series of 'WHEN ... DO ...'  statements) to provide alternative courses of action. All alternative courses of action must be explicitly defined (CIMOSA does not permit the use of imprecise 'else' statements). The different forms of Behavioural Rule are given in Section 1.5 below. Thus the 'flow of action' within one Domain/Business Process is defined by a set of Behavioural Rules. When any Enterprise Activity in a Business Process finishes, its Ending Status (i.e. value defining the termination state) is passed back for processing by the next Behavioural Rule in the set. If the next Behavioural Rule is the last one the finish status of the set of Behavioural Rules is passed back to the calling Business Process for processing according to its Behavioural Rules. This finish status is available as a part of the associated Enterprise Activity or Business Process and is handled by the Business Service of the Integrating Infrastructure.

1.4.2	General Constraints

1.	All the expected Ending Statuses must be explicitly catered for in each given Behavioural Rule.

2.	If execution of any Business Process/Enterprise Activity results in an Ending Status which is not one of those defined in the current set of Behavioural Rules then the CIMOSA Integrating Infrastructure (IIS) must suspend processing of the current set of Behavioural Rules and report the failure to the appropriate responsible authority as defined in the Organisation View.

3.	During the execution of the control flow of a Domain/Business Process, a Behavioural Rule will be fired (i.e. executed) when (a) all its triggering conditions are true and (b) all necessary inputs and pre-conditions of the triggered Business Processes or Enterprise Activities are satisfied.

4.	The set of Behavioural Rules of any process must have at least one rule with START in the triggering condition of the WHEN clause (triggering rule) and at least one rule with FINISH in the action part of its DO clause (completion rule)

1.4.3 Consistency Rule

The set of Behavioural Rules of a process (Domain Process or Business Process) is said to be consistent if and only if (a) FINISH can be reached from all START's (i.e. the set is live) and (b) all functions used in the rules belong to at least one path going from START to FINISH (no dead-ends).

1.4.4	Structured versus Semi-structured Processes

CIMOSA allows the definition of structured as well as semi-structured (or unstructured or ill-structured) processes. A structured process is a process for which the process behaviour (or flow of control) is completely known and deterministic. Typical examples are manufacturing processes for which process plans define the exact sequence of operations to be executed. A semi-structured process is a process for which the exact sequence of its flow of control is not completely known. Typical examples are human-based decision-making processes or cognitive processes such as design processes.

1.5	Description Templates

Behavioural Rules are used in the set of Behavioural Rules associated with a Domain Process or Business Process and are defined in the associated template according to the following general form:

-	WHEN (triggering condition) DO action

where the 'triggering condition' is a logical expression which must evaluate to true to enable the rule, and 'action' defines the set of actions to be taken if the rule is activated (***).

1.5.1	Behavioural Rule of type Process Triggering

Process Triggering Rules are used as first rules in a set of Behavioural Rules and define the triggering conditions of the Domain/Business Process. Triggering Rules for Domain Processes can have the following forms:

-	WHEN (START WITH Event a) DO EFy

-	WHEN (START WITH Event b AND Event c) DO EFz

There can be any number of Events involved in the triggering condition connected by AND. OR conditions are split in several concurrent rules. For instance,

-	WHEN (START WITH Event b OR Event c) DO EFz

will always be split into the equivalent form:

-	WHEN (START WITH Event b) DO EFz

-	WHEN (START WITH Event c) DO EFz

Triggering Rules for Business Processes and Enterprise Activities can have the following forms:

-	WHEN (START) DO EFx

-	WHEN (ES(EFx) = value1) DO EFy

-	WHEN (ES(EFy) = value2 AND Event 1) DO EFz

where EFx, EFy and EFz are Business Processes or Enterprise Activities, "START" in the first rule means "whatever the initial triggering condition is" (can only be used as the first rule of a set of rules for a process triggered by a parent process). In the second rule EFy is triggered upon completion of EFx with ending value value1. In the third rule EFz is triggered upon the completion of EFy with value2 and an occurrence of Event 1. (Event 1 could be a timer or a synchronisation Event). There can be several Ending Statuses of different enterprise functions and possibly several Events involved in the triggering condition connected by AND. Comments in rules are allowed. They always start by '(*' and they terminate by '*)'.

1.5.2	Behavioural Rule of type Forced (****)

Forced Behavioural Rules cause the next Enterprise Activity or Business Process to be activated independent of any status information.

-	WHEN (ES(EFx) = any) DO EFy

where 'any' is a reserved word meaning 'whatever the ending status value of EFx is'.

1.5.3	Behavioural Rule of type Conditional

Conditional Behavioural Rules are used to represent branching conditions in the flow of control. They cause the activation of only one path from different possible paths in the flow of control according to the value of the Ending Status of the completing function. They are logically equivalent to an exclusive OR (XOR) on a set of alternatives. They are represented by rules of the form:

-	WHEN (ES(EF1) = value1) DO EF2

-	WHEN (ES(EF1) = value2) DO EF3

-	WHEN (ES(EF1) = value3) DO EF4

NB.: There is no limit to the number of Ending Statuses that can be tested.

1.5.4	Behavioural Rule of type Spawning

Spawning Behavioural Rules are used to represent the parallel execution of functions in a flow of control. They cause the concurrent activation of two or more defined paths of Enterprise Activities or Business Processes in the process behaviour. Two types of spawning rules exist in CIMOSA: synchronous and asynchronous spawning rules.

a) Asynchronous spawning rules:

In an asynchronous spawning rule two or more paths of the flow of control are logically enabled at the same time when its triggering condition is true but they can effectively start at different times (i.e. when their respective preconditions such as availability of their inputs are satisfied). These are rules of the form:

-	WHEN (ES(EFx) = value1) DO EF1 & EF2 & EF3

where the symbol '&' means 'in parallel to' or 'concurrently to'.

NB.: There is no limit to the number of Business Processes or Enterprise Activities that can be triggered in parallel. These Business Processes or Enterprise Activities can possibly compete for the same Resources.

b) Synchronous spawning rules:

In a synchronous spawning rule all functions listed in the action clause must start exactly at the same time, i.e. when the triggering condition is true and when all preconditions of each function are verified, if any. Synchronous spawning rules are rules of the form:

-	WHEN (ES(EFx) = value1) DO SYNC (EF1 & EF2 & EF3)

where the symbol 'SYNC' means 'synchronously'.

Graphically, a synchronous spawning rule is represented like an asynchronous spawning rule but with a dot at the crossing of the fork lines.

1.5.5	Behavioural Rule of type Rendezvous

Rendezvous Behavioural Rules are used to synchronise the end of spawning rules. They cause, firstly, a wait for all of the paths activated by a defined Spawning Behavioural Rule to be completed and, secondly, the start of one or more Enterprise Activities or Business Processes to be activated. They are described by rules of the form:

-	WHEN (ES(EF1) = value1 AND ES(EF2) = value2 AND ES(EF3) = value3) DO EF4

-	WHEN (ES(EF10) = value10 AND ES(EF20) = value20) DO EF30 & EF40

NB.: There is no limit to the number of Business Processes or Enterprise Activities that can be waited for.

1.5.6	Behavioural Rule of type Looping

The loop mechanism is interesting when a given sequence of enterprise functions has to be repeated until a given condition (i.e. an ending state) has been reached. Loops are always constructed in the following way:

-	WHEN (ES(EFx) = loop_value) DO EFx

-	WHEN (ES(EFx) = end_loop) DO EFy

The loop will be escaped only when the value end loop of the Ending Status of EFx is obtained.

NB.: Nested loops are allowed and constrained by the rule of complete inclusion (no crossing).

Loops must be used carefully and preferably avoided because they are built on GOTO statements. They mean that exactly the same instance of enterprise function (or sequence of enterprise functions) must be executed again until the loop ends. At each pass in the loop a different occurrence of the enterprise function (or sequence of enterprise functions) is executed. Thus if the loop is executed three times before it exits, three different occurrences of the function in the action clause of the loop are executed. Occurrences of input and output Object Views used as Function Input, Function Output and Control Input may be different for each occurrence.

1.5.7	Behavioural Rule of type Completion

These are rules indicating the end of a set of Behavioural Rules. They are of the following forms:

-	WHEN (ES(EFx) = any) DO FINISH

-	WHEN (ES(EFy) = value1 AND ES(EFz) = value2) DO FINISH

The action clause only contains the reserved word 'FINISH'. The triggering condition cannot involve an Event. There is no limitations on the number of Ending Statuses of different enterprise functions which can be involved in the triggering condition.

N.B.: Several rules in a set of Behavioural Rules are allowed to contain the word 'FINISH' in their action clause.

1.5.8	Behavioural Rule of type Run-time Choice

These rules are used when there is an exclusive choice among several possible alternatives. At run-time only one enterprise function among the set of possible enterprise functions will be executed depending on resource choice. This choice can be random. This assumes that all enterprise functions in the set of alternatives are performed by the same resources. These rules have the form:

-	WHEN (ES(EFx) = value1) DO A= (EF1 | EF2 | EF3)

where '|' means 'exclusive OR' and A is the name of the set and is equivalent to a Business Process.

In this case the Ending Status of A is either the Ending Status of EF1 or EF2 or EF3.

1.5.9	Behavioural Rule of type Unordered Set

These rules indicate that a set of enterprise functions must be executed next but the order of execution is not known. In this case all functions must be executed but the exact sequence of execution will be determined at run-time. These rules have the form:

-	WHEN (ES(EFx) = value1) DO A= {EF1, EF2, EF3}

where A is the name of the unordered set and is equivalent to a Business Process.

In this case the Ending Status of A is a logical function of the Ending Statuses of EF1 and EF2 and EF3.

In the case of the unordered set rule, execution of the elementary tasks in the set can be constrained by temporal rules based on Allen's temporal logic defined as follows (where A and B are two different enterprise functions):

A before B: to specify that A must be completed sometime before B starts

A meets B: to specify that B must start just after A ends

A during B: to specify that A must be started after B starts but before B finishes

A starts B: to specify that when A starts, B must start at the same time

A finishes B: to specify that when A ends, B must end

To specify these temporal relations, the WHEN DO rule syntax is extended as follows:

WHEN (triggering condition) DO action SUBJECT TO (temporal relations)

where 'temporal relations' refer to one or more temporal rules as defined earlier and separated by semi-column (;). The clause SUBJECT TO is optional.

2.	Background Section

2.1	Examples

2.1.1	Specific Examples:

Process Triggering: 	first rules in a set of Behavioural Rules defining the triggering conditions of the Domain/Business Process.

-	WHEN (START) DO EF1

-	WHEN (START WITH Event 1) DO EF2

-	WHEN (START WITH Event 1 AND Event 2) DO EF3

where in the first rule "START" means "whatever the initial triggering condition is" (can only be used as the first rule of a set of Behavioural Rules for a Business Process or an Enterprise Activity triggered by a parent process). The second rule illustrates a Domain Process triggered by an Event. The third rule illustrates a Domain Process triggered by a conjunction of Events.

forced:	unconditional execution of next enterprise function

-	WHEN (ES(EF1) = any) DO EF4

where in the rule "any" means whatever Ending Status (i.e. in this example whatever the ending status of EF1 is, EF2 will be started after the execution of EF1).

conditional:	execution of one of several alternative enterprise functions

-	WHEN (ES(EF1) = value1) DO EF2

-	WHEN (ES(EF1) = value2) DO EF3

-	WHEN (ES(EF1) = value3) DO EF4

defines a conditional execution according to the Ending Status of enterprise function EF1.

spawning:	conditional execution of more than one enterprise function. This makes possible the control of parallel processing

-	WHEN (START WITH Event 1) DO EF1 & EF2

-	WHEN (ES(EF1) = value1) DO EF3 & EF4

where the symbol '&' stands for "starts in parallel", the first rule triggers EF1 and EF2 in parallel when an occurrence of Event 1 occurs and where the second rule triggers EF3 and EF4 in parallel if EF1 terminates with value1 as its Ending Status

rendezvous:	the execution of the next enterprise functions depends on the ending statuses of several preceding enterprise functions which were activated by a spawning rule

-	WHEN (ES(EF1) = value1 AND ES(EF2) = value2) DO EF5

loop:	iterative execution of a set of enterprise functions

-	WHEN (ES(EF1) = value1) DO EF1

obviously an Ending Status value other than value1 is required for EF1 to avoid infinite loop in this example.

completion:	rule indicating the end of a process

-	WHEN (ES(EF5) = value5) DO FINISH

where "FINISH" is a reserved word. In this case the process employing this rule finishes with Ending Status value5.

Furthermore, Events such as timers (i.e. values of instants in time) can be used in conjunction with Ending Statuses in triggering conditions. For instance one can write:

-	WHEN (Event 2 AND ES(EF1) = value1 AND time = 15:00) DO EF2

which means that to trigger EF2 we request that EF1 finishes with value1 for its Ending Status, that an occurrence of Event 2 occurs and clock time must be 15:00 hours. This can be used for synchronisation of processes.

2.1.2	General Example:

This example describes the four basic stages of semiconductor manufacturing in which Wafer Fab. Request is an Event.

- WHEN (Wafer Fab. Request) 	DO Wafer Fabrication

- WHEN (ES(Wafer Fabrication) = 'Fab. OK') 	DO Wafer Probing

- WHEN (ES(Wafer Fabrication) = 'Fab. NotOK') 	DO FINISH

- WHEN (ES(Wafer Probing) = 'Wafer OK') 	DO Assembly

- WHEN (ES(Wafer Probing) = 'Wafer NotOK') 	DO Bad Wafer Elimination

- WHEN (ES(Bad Wafer Elimination) = 'Done' 	DO Assembly

- WHEN (ES(Assembly) = 'Packed Dies OK') 	DO Final Test

- WHEN (ES(Final Test) = 'Devices OK') 	DO FINISH

(b) This example illustrates the definition of a design process involving a semi-structured Business Process. The design process concerns the design and testing of a product made of a mechanical subsystem and an electrical subsystem. It is triggered by a design order. Whenever the mechanical system design or the electrical system design fail (ending statuses MSD-pb or ESD-pb), the conceptual development task is done again. The same applies if the prototype test fails (ending status NOK). The semi-structured process concerns the electrical system design.

Domain Process: Product Design

- WHEN (START WITH Design Order)	DO Conceptual Development

- WHEN (ES(Conceptual Development) 	= done) 	DO Mechanical System Design

& Electrical System Design

- WHEN (ES(Mechanical System Design) 	= MSD-pb) 	DO Conceptual Development

- WHEN (ES(Electrical System Design) 	= ESD-pb) 	DO Conceptual Development

- WHEN (ES(Mechanical System Design) 	= MSD-OK

AND ES(Electrical System Design) 	= ESD-OK)	DO Product Prototype

- WHEN (ES(Product Prototype) 	= any)	DO Test

- WHEN (ES(Test) 	= OK)	DO Manufacturing

- WHEN (ES(Test) 	= NOK)	DO Conceptual Development

- WHEN (ES(Manufacturing) 	= done)	DO FINISH

Business Process: Electrical System Design

- WHEN (START) 	DO A = {Rotor Design, Stator Design, Body Design}

SUBJECT TO Rotor Design BEFORE Body Design;

Stator Design BEFORE Body design

- WHEN (ES(A) = completed	DO FINISH

2.2	Document References (none)

2.3	Open Issues

1.	Triggering conditions of Behavioural Rules are based on Ending Statuses and Events in this Release of CIMOSA. However they should not be limited to Ending Statuses. Other conditions can also be applied, e.g.

- WHEN (ES(EFx) AND Order value > $ 100 000) 	DO EFy or

- WHEN (ES(EFx) AND Product Class = 'ABC') 	DO BPm or

- WHEN ((ES(EFx) = value1) AND (Priority > 5)) 	DO EFz

(*)	Previously called Procedural Rule; renamed to avoid inconsistency with public meaning of term Procedural Rule.

(**)	Comments are allowed to indicate events issued.

(***)	Note: In the following ES(EF) is a standard function representing the Ending Status of the enterprise function EF. value a represents a possible value for the Ending Status.
Event a represents an Event and EFx represents a Business Process or an Enterprise Activity.

(****)	The graphical representation is for illustrative purpose only and does not show the AMICE adopted symbols

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Business Process
CIMOSA Technical Baseline

Business Process

B11-2800. Version: 4.3; Last Update: 96.01.28

1.	Technical Section

1.1	Purpose and Scope

Defines the sequence of tasks which represent the business procedures that must be followed to achieve the desired business objectives.

1.2	Terms and Definitions

(1)	Business Process:

(a)	is a construct which describes pieces of enterprise behaviour (Behavioural Rules) at all levels of decomposition in the functional decomposition except the top and bottom levels.

(b)	may have a functional part defined, and must have a behaviour part and a structure part. It is employed by one or more Domain Processes and/or Business Processes and it employs one or more Business Processes and/or Enterprise Activity(ies). It is triggered by a parent structure (Domain Process or Business Process).

1.3	Abbreviations and Acronyms

BP:	Business Process

DM:	Domain

DP:	Domain Process

DR:	Declarative Rule

EV:	Event

O/C:	Objective/Constraint

OC:	Organisation Cell

OV:	Object View

1.4	Description

1.4.1	Generalities

The prime purpose of Business Processes is to define the sequence in which Enterprise Activities and/or lower level Business Processes must be executed to form user-defined intermediate processes of the enterprise. Their objectives and constraints must be sub-objectives and sub-constraints of the employing structure (Domain Process or Business Process). In practice, Business Processes indicate partial sequences of execution (or flow of control) of enterprise functionalities according to happenings or requests occurring in the enterprise or outside the enterprise. Business Processes group lower level Business Processes and/or Enterprise Activities by clustering them according to a specified flow of control (or behaviour).

The functional part of the Business Process defines what has to be done (by its Enterprise Activities and/or Business Processes) in order to meet its objectives and constraints. The behaviour part of the Business Process defines (by means of a set of Behavioural Rules) how to sequence the employed functionalities (Business Processes and/or Enterprise Activities) to achieve the desired output (as indicated by the Function Output). The execution of an occurrence of a Business Process is never directly triggered by occurrences of Events. The activation of its set of Behavioural Rules is initiated by the processing of the set of Behavioural Rules of (one of) its parent structures (Domain Process or Business Process) and operates under the influence of its Declarative Rules, if any, to produce a desired output (defined in its Function Output). A Business Process controls the flow of action according to a set of decisional criteria (Ending Statuses) which are processed according to its Behavioural Rules.

When any Enterprise Activity in a Business Process finishes, its Ending Status is passed back for processing by the next rule in the set of Behavioural Rules of this Business Process. If the next Behavioural Rule is the last one in the set all the Enterprise Activity's Ending Statuses are passed back to the calling Business Process for further processing. Function Input and Function Output can be defined as sets of Object Views for a Business Process at the Requirements Definition Modelling Level for ease of modelling (traceability of inputs and outputs). This is optional. However, they will not be further taken into account in Specified and Implemented Business Processes at other modelling levels. In the case they are defined, they only serve a system description purpose, not a system operation one. Other inputs and outputs are also optional at this modelling level.

1.4.2	Triggering Conditions of Business Processes

In the Enterprise Operation Environment an occurrence of a Business Process can be triggered by:

-	a calling occurrence of a parent structure (Domain Process or Business Process)

-	a triggering condition made of Ending Statuses only of previously completed functionalities

-	a triggering condition involving Ending Statuses of previously completed functionalities and occurrences of Events

Examples for each of these situations follow (See Behavioural Rule item for details on the syntax used):

-	WHEN (START) DO BP-1 (* usually used as a first rule in a set of Behavioural Rules of a Business Process. START is the entry point in the set of rules *)

-	WHEN (ES(BP-1) = value1) DO BP-2 (* BP-2 is triggered upon completion of BP-1 with value1 as Ending Status *)

-	WHEN (ES(BP-2) = value2 AND ES(BP-3) = value3) DO BP-4

-	WHEN (ES(BP-4) = value4 AND Event 2) DO BP-5 (* BP-5 is triggered when both conditions are true: BP-4 finishes with Ending Status value4 and an occurrence of Event 2 has occurred*)

where ES(EF1) is a standard function returning the value of the Ending Status of EF1.

1.5	Description Templates

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Business Process instances of all types are described by the following template.

BUSINESS PROCESS

Header
Type: Identifier: Name: Design Authority:	[relevant category - select from list <name>] [BP-<Unique Identifier>] [name of Business Process instance in the form: <adjective> <noun> <adjective>: qualifying the Business Process instance  <noun>: related to the scope of the Business Process] [<identifier> / <name> of Organisation Unit and/or Organisation Cell with the authority to design/maintain this particular instance]
Body
A. Descriptional Properties OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION INPUTS    FUNCTION INPUT:    CONTROL INPUT:    RESOURCE INPUT: OUTPUTS    FUNCTION OUTPUT:    CONTROL OUTPUT:    RESOURCE OUTPUT: ENDING STATUSES: BEHAVIOURAL RULES: Graphical Representation: B. Relational Properties WHERE USED: COMPRISES:	[non-empty list of <identifier> / <name> of Objective/Constraint defining objectives which must be fulfilled by the Business Process instance;] ['NIL' or list of <identifier> / <name> of Objective/Constraint defining objectives which must be fulfilled by the Business Process instance;] ['NIL' or list of <identifier> / <name> of Declarative Rule instances applicable to this Business Process instance;] [textual description of the tasks performed by this Business Process; optional] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Object View instances, occurrences of which are processed by activities of this process;] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Object View  instances, occurrences of which are used but not processed by activities of this process;] [must be left undefined at this modelling level;] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Object View instances, occurrences of which are produced by activities of this process;] ['NIL' or list of <identifier> / <name> of Event instances, occurrences of which could be generated during the course of occurrences of this Business Process instance;] ['NIL' or list of <identifier> / <name> of Object Views indicating requirements on data collection on resource usage] [non-empty list of Ending Status values and their signification in the form:  <value> : <signification> where  <value> is mandatory and is a 0-argument predicate and  <signification> is optional and is text] [set of formal rules in the form:- When "relevant Business Processes/ Enterprise Activities end and triggering condition becomes true", then do "trigger one or more Business Processes/Enterprise Activities". [optional graphical representation of the Behavioural Rules] each rule is syntactically defined in the following form: - WHEN (<condition>) DO <action>  where <condition> defines the triggering condition and <action>  defines the enterprise function to be executed next. The full syntax  is provided in item B11-2710 of the Formal Reference Base and  called Behavioural Rule. [non-empty list of <identifier> / <name> of Domain Process and/or Business Process instances employing this Business Process instance. Can be left undefined for partial instances] [non-empty list of <identifier> / <name> of all next lower level Business Process or Enterprise Activity instances that are employed by this Business Process instance. Can be left undefined for partial instances]
Remark: By using the optional clause 'STREAM OF', Function Input, Function Output and Control Input can be defined as a stream of Object Views (several occurrences are received in sequence) or as one occurrence of each Object View type indicated.

2.	Background Section

2.1	Examples

BUSINESS PROCESS

Header
Type: Identifier: Name: Design Authority:	Manufacturing Operation/Batch Oriented BP-5.1 'Case Completed' OC-001 'Manufacturing Engineering'
Body
A. Descriptional Properties OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION INPUTS    FUNCTION INPUT:    CONTROL INPUT:    RESOURCE INPUT: OUTPUTS    FUNCTION OUTPUT:    CONTROL OUTPUT:    RESOURCE OUTPUT: BEHAVIOURAL RULES: Graphical Representation: B. Relational Properties WHERE USED: COMPRISES:	O/C-90 'Grant Production Plan at Case Assembly Level O/C-91 'Constraint of Resources and Cost NIL BP-5.1-'Case Completed' models the case assembly area for the gearbox production consisting of the technological production system. OV-095 'Part' (Purchased parts, components) OV-096 'Status information - old' Undefined at this level OV-096 'Case' (Subassembly) OV-097 'Manufacturing Order' (pull) OV-098 'Status information - new' NIL Example Push Mode only WHEN (START WITH Event EV-44 'Gearbox Assembly Order')  DO BP-5.1 WHEN (ES(BP-5.1)= 'Case Completed') DO BP-5.6 Optional (see Domain Process for representation) DP-5 'Gearbox Assembly' tbd
2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Objective/Constraint
CIMOSA Technical Baseline

Objective/Constraint

B11-2900. Version: 4.4; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Defines a construct to represent objectives and constraints at different modelling levels of the Function View.

1.2	Terms and Definitions

(1)	Objectives (see also Domain Objective) describe goals to be achieved by, and

(2)	Constraints (see also Domain Constraint)describe restrictions imposed on Domains or Domain Processes, Business Processes and Enterprise Activity(ies).

1.3	Abbreviations and Acronyms

EO:	Enterprise Object

O/C:	Objective/Constraint

1.4	Description

CIMOSA proceeds in the Function View by functional decomposition. To guide the functional decomposition process, one usually starts by defining the global business objectives and constraints applicable to a Domain, and then break down these objectives and constraints into sub-objectives and sub-constraints to be fulfilled by functions and sub-functions.

Objectives describe goals to be fulfilled by a Domain or a Domain Process, Business Process and Enterprise Activity, whereas constraints describe limits imposed on a Domain or a Domain Process, Business Process and Enterprise Activity. When goals and limits can be measured, objectives and constraints are related to Information Elements (the objective or constraint targets) of Enterprise Objects (the objective or constraint subjects) (*). The Enterprise Objects that are being targeted or constrained (i.e. the subject of the objective or constraint) are for example products, parts, investment, etc.

Examples of values defining limits are '200 units per hour', 'maximum DM 100.000'.

Examples of validity dates are 'from 89.04.01 to 90.03.31'.

Information Element and Enterprise Object are terms defined in the Information View. However, if objectives and constraints do not need to be formally defined, they can be just recorded as pure text (i.e., the formal part of the construct is not used). The construct provides for traceability of objectives and constraints all the way down the functional decomposition hierarchies. For this purpose the template of the construct provides an entry to record parent objectives or constraints.

Two major types of objectives and constraints can be defined: qualitative and quantitative. Qualitative objectives and constraints are objectives and constraints which can only be defined by means of textual statements. In this case, the formal part (reference to an Enterprise Object and one of its Information Elements) is not used and is left undefined. Quantitative objectives and constraints are defined as numeric constraints on the values of some Information Element (see examples). Usually, objectives and constraints are defined at the Requirements Definition Modelling Level. However, they can be revised at other modelling levels when new constructs on which they apply are defined. Also, they remain visible at all modelling levels for constructs using them (e.g. Domains, Enterprise Activities, etc.).

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Objective and constraint instances of all types are described by the following template:

OBJECTIVE/CONSTRAINT

Header
Type: Identifier: Name: Design Authority:	[relevant category - select from list <name>] [OC-<Unique Identifier>] [name of the Objective/Constraint in the form: <noun1> <noun2> <noun3> where      <noun1>: subject of the objective or constraint      <noun2>: either <target> or <constraint>      <noun3>: object of the objective or constraint] [<identifier> / <name> of Organisation Unit and/or Organisation Cell with the authority to design/maintain this particular instance]
Body
A. Descriptional Properties DESCRIPTION: SUBJECT: TARGET: VALUES: VALIDITY: B. Relational Properties INHERITED FROM:	[textual description. Mandatory] [<identifier> / <name> of the Enterprise Object instance which is the subject of the objective or constraint. Optional] [<name> of the Information Element of the Enterprise Object instance which is the target of the objective or constraint. Only used if SUBJECT entry is defined] [<value1> / <value2> where <value1> = lower limit <value2> = upper limit Note: If only one value is given the <value2> must contain  <minimum> or <maximum> or <absolute>. Only used if SUBJECT  entry is defined] [date from: <yy.mm.dd> / date to <yy.mm.dd> where any date can be replaced by <unlimited>. Optional] [List of <identifier> / <name> of Objective/Constraint instances from which this Objective/Constraint instance is inherited]
1.6 Building Block Types

Objective/Constraint Types include:

- Management Objectives/Constraints	Performance Objectives/Constraints
- Operational Objectives/Constraints	Cost Objectives/Constraints
- Functional Objectives/Constraints	Quality Objectives/Constraints
- Design Objectives/Constraints	Reliability Objectives/Constraints
- Implementation Objectives/Constraints	Security Objectives/Constraints
- Time frame Objectives/Constraints
These types are only illustrative examples of families of Objective/Constraint Types that may eventually exist. They have not been approved as official CIMOSA Building Block Types so far.

2.	Background Section

2.1	Examples

Example 1: Some examples of objectives and constraints (including naming)

a.	An investment constraint is imposed for the assembly line:

name: ASSEMBLY LINE INVESTMENT CONSTRAINT 	(system design constraint).

b.	A milling activity is constrained to be used only for certain volumes:

name: MILLING ACTIVITY PRODUCTION VOLUME CONSTRAINT 	(system design constraint).

c.	The assembly line must provide a performance of 1 car per minute:

name: ASSEMBLY LINE PERFORMANCE OBJECTIVE 	(system operations objective).

d.	All plants to reduce current work in progress by 10%.

name: PLANTS WORK IN PROGRESS OBJECTIVE 	(system operations objective).

Example 2:  Example of a qualitative objective using the Objective/Constraint template.

OBJECTIVE/CONSTRAINT

Header
Type: Identifier: Name: Design Authority:	Objective/manufacturing O/C-06 'Motor Assembly Objective' OU-02 'J. P. Smith', OC-001 'Manufacturing Engineering'
Body
A. Descriptional Properties DESCRIPTION: SUBJECT: TARGET: VALUES: VALIDITY: B. Relational Properties INHERITED FROM:	The motor assembly line MA3 is used to produce motors of types M24, M25 and M26. NIL NIL NIL unlimited O/C-05 'Assembly Shop Objective'
Example 3:  Example of a quantitative constraint using the Objective/Constraint template.

OBJECTIVE/CONSTRAINT

Header
Type: Identifier: Name: Design Authority:	Constraint/system design/investment  O/C-014 'Motor Assembly Investment Constraint' OU-02 'J. P. Smith', OC-001 'Manufacturing Engineering'
Body
A. Descriptional Properties DESCRIPTION: SUBJECT: TARGET: VALUES: VALIDITY: B. Relational Properties INHERITED FROM:	The investment for motor assembly is limited to DM 5,000,000 for the new product line. EO-02 'Investment' Investment Amount DM 5,000,000 / maximum. unlimited / 90.09.30 O/C-14 'Motor Assembly Plant Constraint'
2.2	Document References (none)

2.3	Open Issues

1.	CIMOSA recognises that other ways of defining objectives and constraints exist, especially from a mathematical point of view. Further investigations must be made to enlarge the set of objectives and constraints covered by CIMOSA. For instance, the predicate calculus allows the expression of numerical and symbolic constraints of all types in a uniform way. Conversely, Operations Research distinguishes among objectives and constraints and only deals with numerical (and usually linear) constraints as follows:

-	objectives are defined as objective functions which tend to optimise (i.e. maximise or minimise) one or more criteria under some constraints;

-	constraints are defined as numerical expressions on variables of the objective functions.

(*)	Information Element and Enterprise Object are constructs of the Information View.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


RDM Level - Function View
 CIMOSA Outline

 Table of Contents

 Business Oriented Modelling

 RDM Level - Function View

 Function View, Requirements Definition Modelling Level

 Generic Building Blocks of the Function View, Requirements Definition Modelling Level

 Domain

 Domain Objective

 Domain Constraint

 Enterprise Activity

 Function Input

 Function Output

 Control Input

 Control Output

 Resource Input

 Resource Output

 Ending Status

 Event

 Declarative Rule

 Domain Relationship

 Domain Process

 Behavioural Rule

 Business Process

 Objective/Constraint

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Information View, Requirements Definition Modelling Level
CIMOSA Technical Baseline

Information View,

Requirements Definition Modelling Level

B21-1000. Version: 3.0; Last Update: 92.08.26

1.	Technical Section

1.1	Purpose and Scope

Provides the Information View constructs at the Requirements Definition Modelling Level and their relationships as perceived by the CIM system users.

1.2	Terms and Definitions

(1)	Information View, Requirements Definition Modelling Level:

(a)	is the Information View of the Requirements Definition Modelling Level as defined in the European Pre-norm (ENV 40 003).

(b)	consists-of:

non-empty-set-of Generic Building Blocks for requirements definition in the Information View and

set-of Building Block Types for requirements definition in the Information View and

set-of Partial Requirements Definition Models for the Information View and

one Particular Requirements Definition Model for the Information View.

1.3	Abbreviations and Acronyms

CEN:	Comité Européen de Normalisation

ENV:	European pre-Norm

CIM:	Computer Integrated Manufacturing

1.4	Description

At the Requirements Definition Modelling Level the Information View describes:

-	the global business data and information requirements as perceived by top-management and

-	the detailed business data and information requirements in co-operation with interested users.

The CIMOSA Information View is described by Information View Modelling Paradigms.

The Requirements Definition Modelling Level of the Information View is made of three sub-parts:

1.	The Generic Requirements Definition Building Blocks which form a structured catalogue of all Generic Building Blocks and Building Block Types of the Information View used for requirements definition;

2.	The Partial Requirements Definition Models which make up a structured catalogue of classified, (partially) instantiated aggregations of Information View generic constructs used to instantiate Particular Requirements Definition Models;

3.	The Particular Requirements Definition Model which contains all requirements definition for the Information View of one individual enterprise.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	ENV 40 003: Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling. CEN/CENELEC, 1990.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Generic Building Blocks of the Information View, Requirements Definition Modelling Level
CIMOSA Technical Baseline

Generic Building Blocks of the Information View,

Requirements Definition Modelling Level

B21-2000. Version: 3.3; Last Update: 96.02.15

1.	Technical Section

1.1	Purpose and Scope

Provides the list of Generic Building Blocks of the Information View to be used in the CIMOSA Reference Architecture and the Particular Architecture for the definition of business data and information requirements.

1.2	Terms and Definitions

(1)	Generic Building Blocks of the Information View, Requirements Definition Modelling Level:

(a)	are used to build Partial Requirements Definition Models and Particular Requirements Definition Models.

(b)	set of Generic Building Blocks and Building Block Types of Business and IT oriented modelling constructs of the Information View. The set of Generic Building Blocks consists-of:

Business oriented Modelling

-	Enterprise Object - EO

-	Object Relationship - OR

-	Object View - OV

IT oriented Modelling

-	Integrity Rule

(c)	set of Generic Building Block components of the Information View consists of:

Business oriented Modelling

-	Information Element

-	Object Abstraction Mechanisms

IT oriented Modelling

1.3	Abbreviations and Acronyms

CEN: 	Comité Européen de Normalisation

ENV:	European pre-Norm

1.4	Description

Figure B2-2000/1: Generic Building Blocks of the Information View Modelling Paradigms

The CIMOSA Generic Building Blocks of the Information View at the Requirements Definition Modelling Level are used to build up the CIMOSA Information View Modelling Paradigm at this Modelling Level. They form the basis of a semantic object-oriented model to represent business data and information requirements of the enterprise (Booch, 1990; Meyer, 1988, Rumbaugh, 1991). This user "language" is based on the basic concepts of Enterprise Objects, Object Views and Information Elements (see Figure B21-2000/1). Additionally, Object Relationships and Integrity Rules can be defined to represent user-defined information links and constraints. Objects can be semantically linked by Object Abstraction Mechanisms.

Enterprise Objects describe generalised entities of the enterprise which have existence of their own.

Object Views are perceptions or external manifestations of Enterprise Objects and behave as if objects were accessed via some kind of "filters". Object Views are defined as Enterprise Activity Inputs and Outputs.

Information Elements are descriptive properties of Enterprise Objects and therefore of Object Views.

Integrity Rules are constraints defined on Information Elements to ensure their consistency and integrity.

Object Relationships are user-defined links among Enterprise Objects.

In practice, these constructs can be used for rough or detailed requirements definition of the Information System of the CIM system. Rough requirements definition consists in defining only the Object Views, their Information Elements and related Integrity Rules which are referred to in the Function View. Detailed information requirements definition consists in defining all Object Views, their Information Elements and related Integrity Rules that the user can think of and then to define underlying Enterprise Objects and necessary Object Relationships.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	Booch, G. (1990) Object-Oriented Design with Applications, Benjamin-Cummings, Redwood City, CA.

2.	Meyer, B. (1988) Object-Oriented Software Construction, Prentice-Hall, Englewood Cliffs, NJ.

3.	Rumbaugh, J. et al. (1991) Object-Oriented Modelling and Design, Prentice-Hall, Englewood Cliffs, NJ.

4.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

5.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Enterprise Object
CIMOSA Technical Baseline

Enterprise Object

B21-2100. Version: 5.3; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Provides an information representation of data and physical objects of manufacturing enterprises.

1.2	Terms and Definitions

(1)	Enterprise Objects:

(a)	are constructs which describe generalised, real or abstract, uniquely identified, entities of the enterprise's Information System (i.e. things which can be conceptualised or thought about as being a whole), and are characterised by their unique identity, their name and descriptive properties.

(b)	are made of lower level Enterprise Objects (called Sub-Objects) and/or Information Elements, as described by means of Object Abstraction Mechanisms. Conversely, Super-Objects can be constructed from lower level Enterprise Objects.

(c)	are the source of Object Views (set of information elements) which represent a certain aspect of the Enterprise Object and identifying information used and produced in enterprise operations (Input and Output of Domain Process and Enterprise Activity).

1.3	Abbreviations and Acronyms

BOM:	Bill of Materials

CL-data:	Cutting Location data

EO:	Enterprise Object

OU:	Organisation Unit

OC:	Organisation Cell

1.4	Description

1.4.1	General Introduction

The concept of Enterprise Object is the result of a unifying trend to model the whole of the industrial reality through a few universal concepts at a high level of abstraction (Rumbaugh, 1991). This concept can therefore be used at the Requirements Definition Modelling Level, providing a universal, neutral, language to the various groups of users within the Enterprise from which Object Views could be derived. However this concept is not mandatory and can be left out in the definition of a Particular Requirements Definition Model. The user has to decide on the level of semantic detail of his/her model.

Enterprise Objects describe generalised entities of the Enterprise and are defined by attributes (called Properties) which can be either Information Elements or lower-level Enterprise Objects (also called Sub-Objects) or sets of similar Information Elements or Enterprise Objects. Enterprise Objects must have a unique identity, meaning that no two identical Enterprise Objects can exist at any time (they at least differ by their identifier). Thus, this recursive definition allows that groups of Enterprise Objects can also be Enterprise Objects. An Enterprise Object definition must be unique. It is always derived from a set of Object Views. Indeed, an Enterprise Object is a common appellation for a consistent set of Object Views. Object Views are external appearances of Enterprise Objects. Object Views have Embodiment while Enterprise Objects have not.

Enterprise Objects and sub-objects are used to describe highly structured sets of enterprise entities (e.g. products, parts, schedules, Bills of materials, CL-data files, etc.) or unstructured things (e.g. unformatted documents, verbal orders, signals, etc.). A given enterprise entity is an Enterprise Object occurrence. The relationships among Enterprise Objects or among Enterprise Objects and their super-types are either described by means of Object Relationships or by Object Abstraction Mechanisms (such as generalisation and aggregation).

Furthermore, Enterprise Objects are subject to configuration management, meaning that the management of their history in terms of variants and versions may be requested on demand. At the Design Specification Modelling Level, Enterprise Objects and their relationships are described in terms of Entities, Relationships and Attributes in a semantic data model (see B22-series of items). Any Information Modelling Paradigm of the Requirements Definition Modelling Level which in the future is adopted/ recognised/accepted/used by CIMOSA Information View must have the idea of objects at its heart.

1.4.2	Abstraction Relationships

Enterprise Objects and Enterprise Object Types can be linked by semantic links, i.e. natural links relatively to their structure. These links are modelled by Object Abstraction Mechanisms.

CIMOSA makes use of two Object Abstraction Mechanisms (see B21-2110):

-	Generalisation (or ISA link)

-	Aggregation (or PARTOF link)

1.4.3	Object Properties

Definition: Object properties are descriptive fields (or attributes or characteristics) of Enterprise Objects.

Important Property: Each object property must be functionally dependent on the object Identifier. A property Y is functionally dependent on an identifier I if the value of I uniquely determines the value of Y (i.e. no two different Y values can exist for the same value of I) (Ullman, 1982). Properties may take the form of either Information Elements or Enterprise Objects or sets (or lists) of these. They define the structural characteristics of the Enterprise Object.

They are defined on simple data types (integer, real, Boolean, character string, date, money), or complex data types (array, record, list, set, FILE), or as a set or list of Information Elements or Enterprise Objects, or else user-defined data types. See Information Element item.

Nota: In the case of a set (respec., list), an identifier (representing the property name) and the cardinality of the set (respec., the list) i.e. the minimum number and maximum number of occurrences of the set (respec., the list), must be indicated using the following syntax:

<identifier> ": SETOF" <cardinality> <unicity> <element-list> or

<identifier> ": LISTOF" <cardinality> <unicity> <element-list>

where <identifier> is the property identifier, <cardinality> is optional, <unicity> is either the value "UNIQUE" or NIL and <element-list> provides the name of Enterprise Objects or Information Elements in the list

First Important Remark: This mechanism (set of and list of) is a form of aggregation (weak or strong, depending if the entry PARTOF of the corresponding constructs are used or not).

Second Important Remark: In the case of a weak aggregation only it is rigorously equivalent to an Object Relationship, the name of which is the property identifier, describing a 1:n function but not defined as a separate construct. In fact this mechanism can be used in any case instead of the concept of Object Relationship but tends to 'pollute' the pure definition of Enterprise Object.

The choice of the best mechanism to be used is left to the user and no criterion for selection are provided.

1.4.4	Relationship between Enterprise Objects and other Modelling Levels

As far as the Information View is concerned the most Generic Building Blocks used by the user (i.e. at the Requirements Definition Modelling Level) are the Enterprise Objects, the different Object Views on these Enterprise Objects, the Object Relationships, the Information Elements describing them and applicable Integrity Rules. Enterprise Objects and Information Elements are specified by the business users. The CIMOSA user defines the configuration elements (i.e. Versions and Variants) and their relationships with Enterprise Objects, and how to derive and present the Enterprise Objects.

Changing an Enterprise Object, may or may not change some specific Object View of that Object. Similarly, changing the Object View may or may not change the Object itself, but it will provide a new, and better, definition of that Object. A Configuration Management and Control System must control the inter-relationships between different Enterprise Objects and between different Object Views of that Enterprise Object. The difference between an Enterprise Object and an Entity (as used at the Design Specification Modelling Level) is clear-cut and can be established as follows:

-	Entities are simple objects, that is objects whose properties are Information Elements defined on simple data types.

-	Enterprise Objects are generalised Entities, i.e. simple or composite objects the properties of which can be Enterprise Objects and allowing for a recursive definition.

Property: Any Enterprise Object can always be decomposed in terms of a set of Entities and Relationships. Decomposition rules are given in the D0-series of items of the CIMOSA Formal Reference Base.

1.4.5	General Constraints

-	The instantiation of the Enterprise Objects of the Partial Requirements Definition Model and of the Particular Requirements Definition Model is constrained by the defined Enterprise Object Instantiation Rules (described in the D-series of items).

-	Simple Enterprise Objects may only need to be defined by an Entity and a few Attributes in the Conceptual Schema.

-	There is no direct translation between Enterprise Objects at the Requirements Definition level and Entities of the Conceptual Schema at the Design Specification level.

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Enterprise Object instances of all types are described by the following template:

ENTERPRISE OBJECT

Header
Type: Name: Identifier: Design Authority:	[relevant category - select from list] [name of the Enterprise Object instance] [EO-unique number] [<identifier> / <name> of Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance]
Body
A. Descriptional Properties DESCRIPTION: ABSTRACTION RELATIONSHIPS:    ISA:    PARTOF: PROPERTIES: INTEGRITY RULES: B. Relational Properties	[short description] [list of semantic object relationships in the form: ['NIL' or list of <identifier> / <name>  of Enterprise Object types or instances which are a Generalisation of this particular instance. The name of the Enterprise Object instance being defined cannot be used] ['NIL' or list of <identifier> / <name> of Enterprise Object instances in which this particular instance is involved in an Aggregation. The name of the Enterprise Object instance being defined cannot be used]] [non-empty list of Properties of the Enterprise Object instance, each one being either as: an Information Element OR an Enterprise Object defined as: <identifier> ":" <data type>, OR    <identifier> ":" <Enterprise Object instance name>, OR <identifier> ": Setof" <cardinality> <unicity> followed by either a  <data type name> or an <Enterprise Object instance name>.    <identifier> is the property name as defined by the user    <cardinality> ::= "[" <card1> "," <card2> "]". <card1> is the minimum cardinality of the set or the list (0, 1, 2, ...), <card2> is the maximum cardinality (1, 2, ...). If <card2> is unknown and can be large, it is noted # (unbounded) <unicity> ::= "UNIQUE" or NIL indicating if duplicates are allowed in the set or list. This is an optional clause] ['NIL' or list of <identifier> / <name> of Integrity Rule definitions applicable on properties of the Enterprise Object instance]
2.	Background Section

2.1	Examples

2.1.1	End Product (*)

This object description defines end products of an enterprise from an administrative point of view.

ENTERPRISE OBJECT

Header
Type: Identifier: Name: Design Authority:	Product data EO-02 'End Product' OU-03 'S.M. Smith', OC-002 'Product Engineering'
Body
A.  Descriptional Properties DESCRIPTION: ABSTRACTION RELATIONSHIPS:    ISA:    PARTOF: PROPERTIES: INTEGRITY RULES: B. Relational Properties	This type of objects defines the general structure of any enterprise end product. Nil Nil Product_id: string[12] Product_Name: string[15] Description: string[30] Type_Code: string[3] ABC_Code: string[3] Alternate_Code: string[3] Leadtime: integer Standard_Cost: money Unit_of_measure: integer Status: string[8] Creation_Date: date Effectivity_Date: date Discontinued_Date: date Signed_by: string[8] WhereUsed: Setof [0,#] End_Product NIL
2.1.2	Purchase Order (**)

ENTERPRISE OBJECT

Header
Type: Identifier: Name: Design Authority:	Production Management Data EO-04 'Purchase Order' OU-04 'Jean Dupont' OC-005 'Purchasing'
Body
A. Descriptional Properties DESCRIPTION: ABSTRACTION RELATIONSHIPS:    ISA:    PARTOF: PROPERTIES: INTEGRITY RULES: B. Relational Properties	Object description of any purchase order issued by the enterprise Administrative_document Nil Orderid: string[12] Order_Date: date Due_Date: date Delivery_Date: date Order_Status: string[5] OrderedItems: SETOF [1,20] Ordered_Item NIL
2.2	Document References

1.	Rumbaugh J. et al. Object Oriented Modelling and Design, Prentice-Hall, Englewood Cliff, NJ, 1991.

2.	Ullman, J.D., Principles of Database Systems, Second Edition, Computer Science Press, Rockvill, MD, 1982.

2.3	Open Issues (none)

(*)	Note: In this example all Object Properties are Information Elements except the last one, and as such are fully defined in the Information Element Glossary.

(**)	Note: In this example Ordered_Item is a type of Enterprise Objects which describe the list of items required by this order. All other Object Properties are Information Objects.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Object Abstraction Mechanisms
CIMOSA Technical Baseline

Object Abstraction Mechanisms

B21-2110. Version: 5.1; Last Update: 93.12.29

1.	Technical Section

1.1	Purpose and Scope

Defines natural, semantic, links among Enterprise Objects such as generalisation and aggregation.

1.2	Terms and Definitions

(1)	Object Abstraction Mechanisms:

(a)	are semantic links used to connect Enterprise Objects to one another to form a semantic information model of the Information View at the Requirements Definition Modelling Level. They are defined within Enterprise Object descriptions.

(b)	in CIMOSA include the following two mechanisms:

-	Generalisation

-	Aggregation

1.3	Abbreviations and Acronyms

CNC:	Computer Numerical Control

ISA:	reads "is a"

1.4	Description

1.4.1	General Introduction

At the Requirements Definition Modelling Level, the CIMOSA language used for information modelling is an object-oriented language aiming at defining a high-level semantic information model of the Information View.

Figure B21-2110/1: Semantic Modelling Formalism

A semantic information model is a model of the Information System which focuses more on information concepts, their relationships and meaning of the information relatively to the reality of the application rather than focusing on information storage structures and manipulation operations. A semantic information model can be represented by means of a semantic network. In this network, nodes are information concepts (i.e. Enterprise Objects represented by squared boxes) and directed labelled arcs are the relationships among them, described by means of Object Relationships (represented by oriented arrows) and Object Abstraction Mechanisms (as discussed hereafter and illustrated on Figure B21-2110/1).

The Object Abstraction Mechanisms are used to associate concepts of the semantic information model (i.e. Enterprise Objects and their Instances) to one another. They include: Generalisation and Aggregation (Peckam and Maryanski 1988; Hull and King 1987; Shaw et al 1989; Su 1986).

Remark: In the remainder of this item the term 'type' is used in its computer science sense. In object orientation, the terms 'class' or 'object class' are also used with the same meaning.

1.4.2	Generalisation (ISA Link)

Generalisation is an Object Abstraction Mechanism which enables an individual Enterprise Object type to be thought of as a more generic Enterprise Object type (Smith and Smith 1977). This abstraction mechanism is used to organise Enterprise Object types into a hierarchy through a partial order relationship, often referred to as the ISA hierarchy. For example, a manufactured part "is-a" part. Generalisation defines subtype/super type relationships between Enterprise Object types. Its reverse mechanism is called Specialisation (and is not defined in this item).

Property 1: The generalisation mechanism is associated to the concept of property inheritance, meaning that properties of the super type can be inherited by the subtype, unless otherwise specified. For example, properties of a part (such as name, description, weight, price) are also valid for a manufactured part (seen as a specialised part) to which other more specific properties can be applied (such as status, where-used, etc.). This can also be stated as follows:

For each property p of an Enterprise Object O1, if O1 is a generalisation of an Enterprise Object O2, then p is a property of O2.

An Enterprise Object can be involved in two or more ISA links as a child of two or more higher-level Enterprise Objects. This means that this Enterprise Object can inherit properties of two or more super-objects. This is called multiple property inheritance.

Property 2: Any time that a super type is deleted its subtypes must be restructured or deleted since they are fully dependent on the definition of the super type.

Property 3: In a generalisation hierarchy there must be no cycle of the form: x ISA y ISA z ISA x

where x, y and z are Enterprise Objects.

Graphical representation: A ISA link is represented as a directed arrow pointing from the subtype to the super type and identified by the letter G for generalisation.

1.4.3	Aggregation (PARTOF Link)

Aggregation refers to an abstraction mechanism in which an Enterprise Object type is regarded as a permanent, conjunctive, collection of dependent Enterprise Object types. In other words an aggregation typically models a Cartesian product of Enterprise Object types to be itself an Enterprise Object type (since Enterprise Object types are sets in the set theoretic sense).

Aggregation defines one-to-many relationships between Enterprise Object types. This is known as the PARTOF link between dependent Enterprise Object types and an Enterprise Object type.

In CIMOSA two kinds of aggregations are distinguished: strong aggregation and weak (or regular) aggregation.

Strong aggregation: The semantics attached to this kind of links relies in the fact that when an occurrence of the aggregate Enterprise Object is destroyed, the related occurrences of the member Enterprise Objects must also be destroyed. In other words, the life cycle of the member Enterprise Objects, and especially their 'death', is dependent on the life cycle of the parent Enterprise Object. To define such an aggregation the user must use the PARTOF entry in the Enterprise Object template as follows:

Let us assume that Enterprise Object type EO-1 is made of a strong aggregation of Enterprise Object types EO-2 and EO-3. Thus EO-1, EO-2 and EO-3 will be defined as regular objects and EO-2 and EO-3 must make reference to EO-1 in their PARTOF entry.

For instance, if we want that the Enterprise Object type machine_tool be the permanent aggregation of the Enterprise Object types machine_table, machine_controller, machine_spindle, etc. Thus machine_tool will be defined as a regular Enterprise Object having machine_table, machine_spindle and machine_controller as properties. These are themselves described as Enterprise Objects with their own properties and their PARTOF entry must refer to machine_tool.

Weak aggregation: If a property of an Enterprise Object EO-1 is defined as being itself an Enterprise Object EO-2 without having EO-2 being a dependent Enterprise Object (or part of) of EO-1, then whenever an occurrence of EO-1 is destroyed the occurrences of EO-2 used by the occurrence of EO-1 are not destroyed. In this case the PARTOF entry of the member object does not make reference to the aggregate object.

For instance, if we want that the Enterprise Object type machine_tool be an aggregation of the Enterprise Object types machine_table, machine_controller, machine_spindle, etc., but assuming that occurrences of these latter objects can be reused whenever the machine is destroyed, then machine_tool will be defined as a regular Enterprise Object having machine_table, machine_spindle and machine_controller as properties. These are themselves described as regular Enterprise Objects with their own properties and their PARTOF entry must not refer to machine_tool.

CIMOSA then offers two forms of aggregation: one with the dependency property (use of the PARTOF entry of the member object) and one without the dependency property.

Remark: Aggregation of set or list of similar Enterprise Objects is allowed (weak or strong aggregation). In this case the use of a special statement involving the reserved words 'SETOF' or 'LISTOF' must be used in the property definition (see Enterprise Object item).

Graphical representation: An aggregation link (or PARTOF link) is represented as a directed arrow pointing from the subtype to the super type and identified by the expression 'Ag' in a circle for aggregation. In the case of a strong aggregation, 'Ag' is in a double circle.

1.4.6	Concluding Remark

Nothing prevents an Enterprise Object to be involved in several Object Relationships and several Object Abstraction Mechanisms. As an example, let us consider a crew-leader. He is a worker and he is a supervisor. Therefore, he inherits the characteristics of the worker and supervisor object types. Worker and supervisor are themselves specialisation of a higher-level type, person. Now, the crew-leader works in a given department and leads a work-shift.

1.4.7	General Constraints

-	Object Abstraction Mechanisms only apply to Enterprise Objects.

-	The generalisation mechanism is not reflexive, i.e. it is not allowed to define an Enterprise Object as being a generalisation of itself.

1.5	Description Template (not applicable)

2.	Background Section

2.1	Examples

2.1.1	Generalisation

CNC machines, gantry robots and part conveyors are specialised types of machines (Figure B21-2110/2).

Figure B21-2110/2: Generalisation Abstraction Mechanism Example

2.1.2	Weak Aggregation

An assembly is made of reusable component parts (may be disassembled). The entry PARTOF of the Enterprise Object PART is set to 'NIL'  (Figure B21-2110/3).

Figure B21-2110/3: Example of a Weak Aggregation Abstraction Mechanism

2.1.3	Strong Aggregation

An assembly is made of dependent component parts (may not be disassembled). The entry PARTOF of the Enterprise Object PART must indicate the Enterprise Object ASSEMBLY  (Figure B21-2110/4).

Figure B21-2110/4: Example of a Strong Aggregation Abstraction Mechanism

2.2	Document References

1.	M.L. Brodie, 1984, On the Development of Data Models. In On Conceptual Modelling, Perspectives from Artificial Intelligence, Databases, and Programming Languages, M.L. Brodie, J. Mylopoulos, and J.W. Schmidt, Eds. Springer-Verlag, New York, pp. 19-48.

2.	R. Hull and R. King, 1987, Semantic Database Modelling: Survey, Applications, and Research Issues, ACM Computing Surveys, Vol. 19, No. 3, pp. 201-260.

3.	J. Peckam and F. Maryanski, 1988, Semantic Data Models, ACM Computing Surveys, Vol. 20, No. 3, pp. 153-189.

4.	N.K. Shaw, M.S. Bloor, A. de Pennington, 1989, Product Data Models, Research in Engineering Design, Vol. 1, pp. 43-50.

5.	J.M. Smith and D.C.P. Smith, 1977, Database Abstractions: Aggregation and Generalization, ACM Transactions on Database Systems, Vol. 2, No. 2, pp. 105-133.

6.	S.Y.W. Su,1986, Modelling Integrated Manufacturing Data with SAM*, IEEE Computer, Vol. 19, No. 1, pp. 34-49.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Information Element
CIMOSA Technical Baseline

Information Element

B21-2120. Version: 5.1; Last Update: 93.12.30

1.	Technical Section

1.1	Purpose and Scope

Describes an individual piece of data forming the smallest decomposition item of information at the Requirements Definition Modelling Level.

1.2	Terms and Definitions

(1)	Information Elements at the Requirements Definition Modelling Level: are constructs used to represent any items of information which, for the purposes they are being used, are indivisible, i.e. atomic, in an Enterprise Object or one of its Object Views. Each Information Element is defined on a given data type.

1.3	Abbreviations and Acronyms

ASCII: 	American Standard Code for Information Interchange

CAD: 	Computer-Aided Design

CAEE: 	Computer-Aided Enterprise Engineering

IGES: 	Initial Graphics Exchange Standard

STEP: 	Standard for the Exchange of Product Data

1.4	Description

1.4.1 	General Definition

An Information Element is any item of information which, for the purposes it is being used at the Requirements Definition Modelling Level, is indivisible. It represents the lowest level of granularity, or atomic level, of modelling in the CIMOSA Information View at the Requirements Definition Modelling Level. It is a single piece of information (defined on simple data types such as an attribute), a structured amalgam of items of information (defined on complex data types) or a non-formatted file structure.

Data types for Information Elements are of four kinds and should cover the set of data types required for CIM environments as indicated in item B2-2300 Data Type Capabilities (use of international standards for data type formats will be adopted whenever possible):

-	Basic (or simple) data types:

-	integer (signed or unsigned integer numbers)

-	real (real numbers)

-	Boolean (true or false)

-	character (any ASCII symbol)

-	character string (fixed-length or unlimited)

-	text (for formatted text)

-	date (in the format yy.mm.dd:hh.mn.ss) where yy stands for year, mm for month, dd for day, hh for hour, mn for minute and ss for second. The time part :hh.mm.ss is optional)

-	money (money amount in the format: <currency> m.n where <currency> is "£", "$", "CAD", "DM", "FF", "FEB", etc. m is the integer part and n is the decimal part on two digits)

-	Complex (or compound) data types:

-	array structure (in the format: array [n1, n2, ..., nl of type] where n1, n2, ..., nl are l integers and type is a basic data type of fixed length)

-	record structure ( in the format: record v1:t1, v2:t2, ..., vn:tn end where v1, v2, ..., vn are field names and t1, t2, ..., tn are basic data types)

-	list structure (ordered set of values)

-	set (unordered set of values)

-	User-defined:

-	arrays of arrays

-	arrays of records

-	records containing arrays

-	records containing lists or sets

-	lists or sets of arrays

-	lists or sets of records

-	formatted file contents for non-alphanumerical data with format indication such as:

-	FILE (IGES, STEP, ...)

Information Elements are used to describe atomic properties of Enterprise Objects, respectively Object Views (i.e. properties which are not Enterprise Objects, respectively Object Views).  Furthermore, some Information Elements of some Object Views may be derived from other Information Elements of some Enterprise Objects (i.e. their values are calculated from other values), and thus do not belong to any specific Enterprise Objects. In this case, the relation linking these Information Elements is defined as an Integrity Rule on the derived Information Element.

Information Elements (as part of Object Views) play a significant input/output role in Enterprise Activities. Each Information Element will be described at the Design Specification Modelling Level as being a single Attribute, a calculated Attribute, or (part of) an Entity, or an amalgam of several Entities and/or Relationships depending on the Information Element complexity. Thus, Information Elements can have a concrete physical reality in the Enterprise (they really exist as groups of data items) or they can have an abstract reality (they represent aggregated or synthetic pieces of information derived from concrete ones).

An Information Element is the result of applying the part of the Derivation Process to an Enterprise Object. Thus, it is one step in abstracting the textual description of an Enterprise Object, and its Object Views. A special type of Information Element, called FILE, has been introduced in CIMOSA to consider the content of a whole file as one property of an Object View or Enterprise Object. This is particularly useful to refer to the content of CAD files (in neuter format or not) or of other structured or unstructured files. Special formats of files can be considered (such as IGES, STEP, ...).

For instance, when an Enterprise Activity needs to manipulate a data file, the physical file is an Object View, the properties of which can be: the file name, all necessary attributes used to describe the status of the file (creation date, version, author, etc.) and the content of the file (of type FILE).

Information Elements are described in CIMOSA in terms of the Enterprise Objects or Object Views from which they originates (Belongs to), the Enterprise Objects which use them (Related Objects) and the Object Views which use them (Related Views).

1.4.2	General Constraints

-	The instantiation of Information Elements at the Partial and Particular Requirements Definition Modelling Level is constrained by the defined Information Element Type Instantiation Rules (described in the D-series Items).

-	Only meaningful Information Elements with a concrete (physical or abstract) reality for the Enterprise must be defined in the Information View. This means that Information Elements defined must be used either by some Object View(s) or Enterprise Object(s) or as Control Input of at least one Enterprise Activity.

1.5	Description Template (not applicable)

2.	Background Section

2.1	Examples

Examples can be found in Enterprise Object and Object View items.

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Object View
CIMOSA Technical Baseline

Object View

B21-2200. Version: 5.3; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Describes aspects of one or more Enterprise Objects as they are perceived by some group of users. They are made of Information Elements or other Object Views. Involved in Function Input, Function Output and Control Input of Enterprise Activities.

1.2	Terms and Definitions

(1)	Object View: the description of one aspect of one or more Enterprise Objects. It therefore describes a subset of properties owned by one or more Enterprise Objects from a given stand-point. It is made of Information Elements and/or other Object Views.

1.3	Abbreviations and Acronyms

EO:	Enterprise Object

OC:	Organisation Cell

OU:	Organisation Unit

OV:	Object View

1.4	Description

Complex Enterprise Objects require descriptions of different nature, with intervention of different disciplines. They provide a unified, abstract, representation of real-world objects. Different individuals within an Enterprise might have differing, more or less complicated, but compatible, visions of the same Enterprise Object. Each of these visions will see the Enterprise Object from only one stand-point, and will see only part of the complete object as a whole. The term Object View is used to describe these partial images of an Enterprise Object at the Requirements Definition Modelling Level. A user may be able to see all of an Enterprise Object via an Object View, but if he/she is only interested in part of that object, the Object View will be used to restrict his/her vision. Note, however, that except for the simplest of Enterprise Objects the user will rarely, if ever, want to see all of an object.

For Enterprise Objects having a physical Embodiment, the physical Embodiment is itself an Object View. An Object View can also be defined on a set of Enterprise Objects, putting together descriptive properties (i.e. Information Elements) of each one to form a whole. In fact, an Object View is a recursive construct and is defined by:

-	its name,

-	the leading Enterprise Object it is defined on,

-	the other related Enterprise Objects it is defined on (when it is defined on several Enterprise Objects),

-	the list of properties which characterise it, and

-	some constraints on the definition of some of its properties as well as a selection clause constraining the set of possible occurrences allowed in the extension of the Object View.

Properties of an Object View can be either Information Elements, other Object Views, or sets or lists of Information Elements (i.e. values with a data type) or Object Views or sets or lists of Information Elements or Object Views. Most of these properties, except Object Views, are properties of the leading or related Enterprise Objects. Some can be Information Elements calculated from Information Elements of related Enterprise Objects. The leading Enterprise Object is the Enterprise Object which is the main focus of the Object View. Related Enterprise Objects are other Enterprise Objects from which Information Elements of the Object View are extracted (*). Furthermore, it is important to be able to recognise

-	that different kinds of information pertain to the same Enterprise Object, and are thus linked to each other by a common identifier (the Enterprise Object identifier),

-	and that these different kinds of information intervene differently in different Enterprise Activities and Business Processes.

Thus, an open information architecture, able to expand for build purposes the system in a compatible way, and giving means to verify consistency without necessitating its direct enforcement, is based on a split-up of the information in Object Views. Each Object View defined at the Requirements Definition Modelling Level defines a stable window from the user's viewpoint on the Conceptual Schema to be defined at the Design Specification Modelling Level (**). It is made up of an aggregation of Information Elements or other Object Views and will be transformed into one or more External Schemata at the Design Specification Modelling Level. There is a very large, but finite number of possible Views of an Enterprise Object. Examples of engineering viewpoints from which Object Views can be defined include: Quality, Structural, Stress, Electronic, Mechanical, Plumbing, etc.

Physical vs. Information Object Views:

CIMOSA distinguishes two major classes of Object Views: physical Object Views and Information Object Views. Physical Object Views refer to physical objects of the real-world having an embodiment (e.g. the embodiment of a motor car). Information Object Views are Object Views made of information objects only (i.e. Information Elements or Object Views themselves containing Information Elements). For instance the inspection records, the design calculations, the geometry of the body of the car are information Object Views of the motor car.

Physical Object Views are embodiments of Object Views (in other words of Enterprise Objects). Thus they provide a convenient way to model the flow of physical objects (e.g. materials, parts, components, tools, etc.). Physical Object Views are not distinguishable from other Object Views at design and implementation modelling levels except by a status since at this level they are 'information about physical objects' (such as object id, position, status, etc.).

Important Comment 1: From the information analysis point of view, it is assumed that only Object Views and Information Elements are involved in Function Inputs, Function Outputs and Control Inputs of Enterprise Activities. Thus, Object Views are one of the major hooks between the Function View and the Information View of CIMOSA at the Requirements Definition Modelling Level.

Important Comment 2: Since Object Views can be of two natures, information and physical, and since Object Views are involved in Function Input, Function Output and Control Input of Enterprise Activities, an interesting property of the CIMOSA model is that one can derive and then analyse from a particular model of an enterprise (or part of it):

-	the information flow (concentrating on information Object Views)

-	the part/material flow (concentrating on physical Object Views)

-	the resource flow (only when the resource object is moved from one place to another as an object, i.e. as part of some Function Input or Function Output of some Enterprise Activities)

1.4.1	General Constraints

-	The instantiation of Object Views at the Partial and Particular Requirements Definition Modelling Level is constrained by the defined Object View Instantiation Rules (described in the D-series Items).

-	All Object Views defined at the Requirements Definition Modelling Level will be transformed into External Schemata at the Design Specification Modelling Level.

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Object View instances of all types are described by the following template:

OBJECT VIEW

Header
Type: Identifier: Name: Design Authority:	[relevant category - select from list] [OV-unique number] [name of the Object View] [<identifier> / <name> of Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance]
Body
A. Descriptional Properties Nature Description: PROPERTIES: CONSTRAINTS: B. Relational Properties LEADING OBJECT: RELATED OBJECTS:	['Physical' or 'Information'] [short description] [list of Properties of the Object View instance, defined either as: - <identifier> ":" <data type name>, OR - <identifier> ":" <Object View instance name>, OR - <identifier> ": Setof" <cardinality> <unicity> followed by either an       <data type name> or an <Object View instance name>, OR - <identifier> ": Listof" <cardinality> <unicity> followed by either an       <data type name> or an <Object View instance name>.       - <identifier> is the property name as defined by the user      - <cardinality> ::= "[" <card1> "," <card2> "]". <card1> is the           minimum cardinality of the set or the list (0, 1, 2, ...),            <card2> is the maximum cardinality (1, 2, ...).                 If <card2> is unknown and can be large, it is noted #      - <unicity> ::= "UNIQUE" or NIL indicating if duplicates are allowed in           the set or list. This is an optional clause] [list of constraints applicable to properties the Object View instance. The selection clause starts by the reserved word "WHERE" and is made of a conjunctive list of first-order predicates; optional] [<identifier> / <name> of the main Enterprise Object instance on which the Object View instance applies]  list of <identifier> / <name> of other Enterprise Object instances related to the Object View instance]
2.	Background Section

2.1	Examples

The following example describes an Object View, called Product Data, of an Enterprise Object, called End Product, described as an example in the Enterprise Object item.

OBJECT VIEW

Header
Type: Identifier: Name Design Authority	Product Data  OV-10 'Product Data' OU-05 'K. Maier', OC-006 'Sales Department'
Body
A. Descriptional Properties Nature: Description: PROPERTIES: CONSTRAINTS: B. Relational Properties LEADING OBJECT: RELATED OBJECTS:	Information Product description from the sales department viewpoint Product_id:string[12] Product_Name:string[15] Description:string[30] Type_Code:string[5] Alternate_Code:string[5] ABC_Code:string[3] Leadtime:integer Standard_Cost:money Unit_of_Measure:integer Drawing_Id::string[12]  Exist (Product_id); WHERE (Type_Code LIKE "ABC$") AND Leadtime <= 50 EO-02 'End Product' EO-03 'Product History'
The constraint defined in this Object View means that (1) any occurrence of this view must be provided with a value for the Product_id and (2) that any occurrence of the view must satisfy the WHERE clause (i.e. the Type_Code must start with ABC and the lead-time must be less than 50 days).

2.2	Document References (none)

2.3	Open Issues

1.	Syntax of language to be used for the constraint definition of the description template to be defined.

(*)	Note: When an Object View is defined it may happen that the Enterprise Object(s) on which it is defined is (are) not known. In this case the leading and related Enterprise Object entries of the construct are left undefined as long as the Enterprise Object(s) has (have) not been defined. These entries need in fact to be defined if the model has to be complete and consistent.

(**)	Note however that a particular Object View of an Enterprise Object can be the Enterprise Object description itself.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Object Relationship
CIMOSA Technical Baseline

Object Relationship

B21-2600. Version: 4.2; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Defines application dependent, user-defined, links among Enterprise Objects.

1.2	Terms and Definitions

(1)	Object Relationships: are constructs which describe user-defined relations between two Enterprise Objects of the enterprise Information System.

(2)	Object Relationship (Graphical Formalism): are represented by directed labelled arcs between two Enterprise Objects represented by boxes with their name inside. The arc is a single arc if it is a one-to-one relationship, has one end as a craws-foot if it is a one-to-many relationship and has a craws-foot on both ends if it is a many-to-many relationship.

1.3	Abbreviations and Acronyms

EO:	Enterprise Object

OC:	Organisation Cell

OU:	Organisation Unit

OR:	Object Relationship

1.4	Description

1.4.1	General Introduction

The concept of Object Relationship is dependent on the concept of Enterprise Object. It is used to describe application-dependent links between Enterprise Objects as perceived and defined by the users. These links are created for the purpose of the CIM system applications. They do not tend to describe natural relations between Enterprise Objects. 'Applications' here refer to the way users group Enterprise Objects in terms of their utilisation within the enterprise. Object Relationships have a graphical representation in the form of directed labelled arcs connecting two boxes. Boxes represent Enterprise Objects involved in the relationship. An arc labelled "links" connects two Enterprise Objects EO-1 and EO-2 in the sense (i.e. in the semantic meaning) of the relationship and reads "EO-1 links EO-2". See section 2.1 for an example.

Property: Reflexive Object Relationships are allowed, i.e. a link can be created between an Enterprise Object and itself.

1.4.2	Graphical Representation

Object Relationships have a graphical representation (See example in section 2.1). Since these are binary relationships they are represented by a directed arc labelled by the relationship name. The arc connects the two Enterprise Objects represented by squared boxes with their name inside. The arc is a single arc if it is a one-to-one relationship, has one end as a craws-foot if it is a one-to-many relationship and has a craws-foot on both ends if it is a many-to-many relationship.

1.4.3	Relationship of Object Relationships to other Modelling Levels

A particular Object Relationship exists only in the Particular Requirements Definition Model. Object Relationships will be transformed into Entity Relationships in the Conceptual Schema of the Information View of the Design Specification Model. However, there is no direct translation mechanism from Object Relationships to Entity Relationships.

1.4.4	Discussion About Object Relationships

In most object-oriented models the concept of Object Relationship is embedded in the definition of object classes (in CIMOSA terms, Enterprise Objects) since it is a function from one object class to another object class. Thus in a CIMOSA model any time that a weak aggregation between two Enterprise Objects is defined (see Enterprise Object item), this is strictly equivalent to defining an Object Relationship, except that the name of this relationship usually remains undefined and the cardinality is not defined.

On one hand one may argue that this construct is superfluous. On the other hand having makes the advantage of describing a real-world situations (user-defined connections between two Enterprise Objects). Furthermore its existence provides a purer definition of Enterprise Objects, i.e. Enterprise Object definitions which are not overloaded or 'polluted' by non-relevant properties (i.e. pointers to other Enterprise Objects). Remember that ideally all properties of an Enterprise Object should be functionally dependent on this Enterprise Object.

1.4.5	General Constraints

-	Instantiation of the Object Relationships of the Partial Requirements Definition Model and of the Particular Requirements Definition Model is constrained by the defined Object Relationship Instantiation Rules.

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Object Relationship instances of all types are described by the following template:

OBJECT RELATIONSHIP

Header
Type: Identifier: Name: Design Authority:	[relevant category - select from list] [OR-unique number] [name of the Object Relationship instance]  [<identifier> / <name> of Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance]
Body
A. Descriptional Properties DESCRIPTION: ORIGINATOR: RELATED TO: FUNCTIONALITY: B. Relational Properties	[short description] [Enterprise Object instance name] [Enterprise Object instance name] [1:1 or 1:n or n:1 or m:n]
2.	Background Section

2.1	Examples

2.1.1	End Product

This object description defines end products of an enterprise from a high-level point of view.

OBJECT RELATIONSHIP

Header
Type: Identifier: Name: Design Authority:	Product data OR-01 'Make' OU-03 'S.M. Smith', OC-002 'Product Engineering'
Body
A. Descriptional Properties DESCRIPTION: ORIGINATOR: RELATED TO: FUNCTIONALITY: B. Relational Properties	This type of object relationship defines the relation between a part object type and a machine_tool object type. EO-05 'Machine Tool' EO-04 'Part' m:n
2.1.2	Graphical Representation

The Object Relationship Makes is represented by a directed arc labelled by the relationship name and indicates functionality connecting the two Enterprise Objects Machine_Tool and Part as illustrated by Figure B21-2600/1.

Figure B21-2600/1: Object Relationship Example

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


RDM Level - Information View
  CIMOSA Outline

 Table of Contents

 Business Oriented Modelling

 RDM Level - Information View

 Information View, Requirements Definition Modelling Level

 Generic Building Blocks of the Information View, Requirements Definition Modelling Level

 Enterprise Object

 Object Abstraction Mechanisms

 Information Element

 Object View

 Object Relationship

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Resource View, Requirements Definition Modelling Level
CIMOSA Technical Baseline

Resource View,

Requirements Definition Modelling Level

B31-1000. Version: 0.6; Last Update: 93.12.31

1.	Technical Section

1.1	Purpose and Scope

Provides the constructs to describe enterprise resources at the Requirements Definition Modelling Level and their relationships as perceived by the user.

1.2	Terms and Definitions

(1)	Resource View, Requirements Definition Modelling Level:

(a)	is the Resource View of the Requirements Definition Modelling Level as defined in the European Pre-Norm (ENV 40 003).

(b)	consists-of:

-	non-empty-set-of Generic Building Blocks for requirements definition in the Resource View and

-	set-of Building Block Types for requirements definition in the Resource View and

-	set-of Partial Requirements Definition Models for the Resource View and

-	one Particular Requirements Definition Model for the Resource View.

1.3	Abbreviations and Acronyms

CEN:	Comité Européen de Normalisation

ENV:	European Pre-Norm

1.4	Description

At the Requirements Definition Modelling Level the Capability Sets needed for the execution of the Enterprise Activities defined in the Function View are described. Classes of Capability Sets could be :

-	Machine Capability Set

-	Application Capability Set

-	Human Capability Set

The CIMOSA Resource View is described by Resource View Modelling Paradigms :

The Requirements Definition Modelling Level of the Resource View is made of three sub-parts:

1.	The Generic Requirements Definition Building Blocks which form a structured catalogue of all Generic Building Blocks and Building Block Types of the Resource View used for requirements definition;

2.	The Partial Requirements Definition Models which make up a structured catalogue of classified, (partially) instantiated aggregations of Resource View generic constructs used to instantiate Particular Requirements Definition Models;

3.	The Particular Requirements Definition Model which contains all requirements definitions for the Resource View of one individual enterprise.

2.	Background Section

2.1	Examples (not applicable.)

2.2	Document References

1.	ENV 40 003: Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling. CEN/CENELEC, 1990.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Generic Building Blocks of the Resource View, Requirements Definition Modelling Level
CIMOSA Technical Baseline

Generic Building Blocks of the Resource View,

Requirements Definition Modelling Level

B31-2000. Version: 0.6; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Provides the list of Generic Building Blocks of the Resource View to be used in the CIMOSA Reference Architecture and the Particular Architecture for the definition of resource requirements.

1.2	Terms and Definitions

(1)	Generic Building Blocks:

(a)	are used to build Partial Requirements Definition Models and Particular Requirements Definition Models.

(b)	set of Generic Building Blocks and Building Block Types of the Resource View. The former consists of:

-	Capability Set - CS

(c)	set of Generic Building Block components of the Resource View consists-of

-	Capability Element

1.3	Abbreviations and Acronyms

CEN:	Comité Européen de Normalisation

ENV:	European Pre-Norm

1.4	Description

CIMOSA Generic Building Blocks of the Resource View are used to build up CIMOSA Resource View Modelling Paradigms. A modelling paradigm is a structured, open set of primitive and high-level concepts, models, languages, methods and methodologies which are used to describe the static and dynamic properties of the Physical and Decision Systems of manufacturing Enterprises. During the Requirements Definition Modelling process the Capability Sets required by the Enterprise Activities are provided. These "required Capabilities" represent the resource requirements.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Capability Set
CIMOSA Technical Baseline

Capability Set

B31-2100. Version: 0.6; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Defines a set of Capabilities required by Enterprise Activities at the Requirements Definition Modelling Level. Capabilities will be needed by Resources to support the execution of these Enterprise Activities.

1.2	Terms and Definitions

(1)	Capability Set: is a Generic Building Block and is defined as a collection of Capability Elements or Capabilities. It describes the set of Capabilities required by Enterprise Activity(ies).

1.3	Abbreviations and Acronyms

DM:	Domain

DP:	Domain Process

EV:	Event

OC:	Organisation Cell

O/C:	Objective/Constraint

OV:	Object View

OU:	Organisation Unit

RL:	Domain Relationship

1.4	Description

Figure B31-2100/1: Capability Set and its relation to the Function View

Capability Set describes the capabilities required by an Enterprise Activity. This is part of the definition of an Enterprise Activity (see Figure B31-2100/1). Each Capability is defined by its name and value OR a set of enumerated values OR a range of values. They represent technical limitations , i.e. constraints on task realisation. The Capability Set construct can be used to define aggregated or detailed Capabilities according to the level of details defined for a particular Enterprise Activity. The Object Abstraction Mechanism described in the Information View can be applied for the recursive use of the Capability Set construct as well. Building Block Types of Capability Sets are possible for Human, Machine and Application Capabilities. Capability Set is used to describe :

Function Related Capabilities: A Function Related Capability concerns the functionality of an Enterprise Activity and will be provided by a Resource. Examples are metal cutting or drilling of deep holes.

Object Related Capabilities: An Object Related Capability applies to input objects of an Enterprise Activity or to that processed by a Resource like the range between minimum and maximum size or weight of a tool.

Performance Related Capabilities: A Performance Related Capability is required by an Enterprise Activity or provided by a Resource. Examples are time performance, throughput or availability of a manufacturing cell.

Operation Related Capabilities: An Operation Related Capability constrains operation related attributes required by an Enterprise Activity or provided by a Resource. Examples are skill of personnel or number of shifts per day.

Each Capability is an element, not a construct, with a name and a value range, e.g. max. elongation of 1.5 meter, tool diameter of 0.5 - 1.5 cm or spoken languages as English, French, German. A Capability called "Required Resource" can be defined to identify a Resource if the Resource is known at the Requirements Definition Modelling Level. The same Capability Set can be referred to by several Enterprise Activity instances.

In the case of Human Capabilities, and especially the Operation Related Capabilities, one may define human competencies, e.g. the ability and qualification to perform a task instead of the capability of doing a task. For instance cognitive abilities (to plan, to decide, to solve problems, etc.).

1.5	Description Template

CAPABILITY SET

Header
Type: Identifier: Name: Design Authority:	[Relevant category - select from list] [RC-unique number] [name of this set of Capabilities] [<identifier> / <name> of Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance]
Body
A. Decriptional Properties DESCRIPTION: CAPABILITIES :    Function Related:    Object Related    Performance Related:    Operation Related: B. Relational Properties WHERE USED:	[NIL or list of Capabilities Elements separated by semi-colon] [NIL or list of Capabilities Elements separated by semi-colon]  [NIL or list of Capabilities Elements separated by semi-colon]  [NIL or list of Capabilities Elements separated by semi-colon]  list of [<identifier> / <name> of Enterprise Activities which require Capability Set] (the same Capability Set may be defined for several Enterprise Activities)
There must be at least one Capability Element defined in a Capability Set. Each Capability Element is defined as: <name> ":" <range> <unit>, where: <range> defines the constrained values of the capability and <unit> indicates the unit of measure if required

<range> is either:

-	free text

-	a value (integer, real, string, Boolean)

-	a range of values defined either as:- [a, b] means the value is between a and b where a and b are either both integers or both reals

- 	[-, b] means the value is less than b

- 	[a, -] means the value is greater than a

-	an enumeration of values separated by comma and enclosed by parentheses (e.g. (blue, green, yellow). 	All values in the enumeration must have the same data type.

<unit> is optional and can take usual abbreviation values of the international metric system (e.g. m, cm, N/m, Kg, etc.)

2. 	Background Section

2.1	Examples

CAPABILITY SET

Header
Type: Identifier: Name: Design Authority:	Move Class1 CS-02 'Moving Packed Products' OC-003 'Production Control'
Body
A. Decriptional Properties  DESCRIPTION: CAPABILITIES : Function Related: Object Related Performance Related: Operation Related: B. Relational Properties WHERE USED:	3-shift operation transportation of mechanical products packed in wooden boxes 3-dimensional movement inside building: (200x200x4 m3);  acceleration: < 0,1g; vibration tolerances: < 2Hz; Size: up to 1x1x1m3; Weight: up to 500 Kg Average number of boxes to be moved: up to 50/h Operation: 3 shifts EA-03 'Move Packed Product'
2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


RDM Level - Resource View
 CIMOSA Outline

 Table of Contents

 Business Oriented Modelling

 RDM Level - Resource View

 Resource View, Requirements Definition Modelling Level

 Generic Building Blocks of the Resource View, Requirements Definition Modelling Level

 Capability Set

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


RDM Level - Organisation View
 CIMOSA Outline

 Table of Contents

 Business Oriented Modelling

 RDM Level - Organisation View

 Organisation View, Requirements Definition Modelling Level

 Generic Building Blocks of the Organisation View, Requirements Definition Modelling Level

 Organisation Cell

 Organisation Unit [image] Organisation Element

 Organisational Guidelines and Constraints

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Organisation View, Requirements Definition Modelling Level
CIMOSA Technical Baseline

Organisation View,

Requirements Definition Modelling Level

B41-1000. Version: 2.2; Last Update: 94.02.15

1.	Technical Section

1.1	Purpose and Scope

Provide the Organisation View constructs at the Requirements Definition Modelling Level and their relationships as perceived by the CIM system users.

1.2	Terms and Definitions

(1)	Organisation View, Requirements Definition Modelling Level:

(a)	is the Organisation View of the Requirements Definition Modelling Level as defined in the European Pre-Norm (ENV 40 003).

(b)	consists-of:

-	non-empty-set-of Generic Building Blocks for requirements definition in the Organisation View and

-	set-of Building Block Types for requirements definition in the Organisation View and

-	set-of Partial Requirements Definition Models for the Organisation View and

-	one Particular Requirements Definition Model for the Organisation View.

1.3	Abbreviations and Acronyms

CEN:	Comité Européen de Normalisation

ENV:	European Pre-Norm

1.4	Description

At the Requirements Definition Modelling Level the Organisation View describes:

-	the global organisational business requirements as perceived by top-management and

-	the detailed organisational business requirements in co-operation with interested users.

The CIMOSA Organisation View is described by Organisation View Modelling Paradigms. The Requirements Definition Modelling Level of the Organisation View is made of three sub-parts:

1.	The Generic Requirements Definition Building Blocks which form a structured catalogue of all Generic Building Blocks and Building Block Types of the Organisation View used for requirements definition;

2.	The Partial Requirements Definition Models which make up a structured catalogue of classified, (partially) instantiated aggregations of Organisation View generic constructs used to instantiate Particular Requirements Definition Models;

3.	The Particular Requirements Definition Model which contains all requirements definitions for the Organisation View of one individual enterprise.

2.	Background Section

2.1	Examples (Not applicable)

2.2	Document References

1.	CEN/CENELEC, 1990: Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling, ENV 40 003.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Generic Building Blocks of the Organisation View, Requirements Definition Modelling Level
CIMOSA Technical Baseline

Generic Building Blocks of the Organisation View,

Requirements Definition Modelling Level

B41-2000. Version: 1.5; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Provide the list of Generic Building Blocks of the Organisation View to be used in the CIMOSA Reference Architecture and the Particular Architecture for the definition of business user requirements.

1.2	Terms and Definitions

(1)	Generic Building Blocks of the Organisation View, Requirements Definition Modelling Level:

(a)	are used to build Partial Requirements Definition Models and Particular Requirements Definition Models.

(b)	set of Generic Building Blocks and Building Block Types of the Organisation View. The former consists-of:

-	Organisation Cell - OC

-	Organisation Unit - OU

(c)	set of Generic Building Block components of the Organisation View consists-of

-	Organisation Element

Note: Abbreviations are used in the templates for construct identification

1.3	Abbreviations and Acronyms

CEN:	Comité Européen de Normalisation

ENV:	European Pre-Norm

1.4	Description

Figure B41-2000/1: Generic Building Blocks of the Organisation View Modelling Paradigm

The CIMOSA Generic Building Blocks of the Organisation View at the Requirements Definition Modelling Level are used to build up the CIMOSA Organisation View Modelling Level. The constructs of this modelling level are essentially used to define the problem. They do not deal with time and occurrences of constructs or system status. This user "language" is based on the basic concept of Organisation Cells, Organisation Units and Organisation Elements. Additionally, Organisation Relationships can be defined to represent user defined organisational links.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Organisation Cell
CIMOSA Technical Baseline

Organisation Cell

B41-2100. Version: 1.2; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Describes the construct of the Requirements Definition Modelling Level for dividing an enterprise or part of it into sections.

1.2	Terms and Definitions

(1)	Organisation Cell:

(a)	is the description of an organisational area.

(b)	Organisation Cells are constructs which describe generalised, real or abstract, uniquely identified, entities of the enterprise«s formal organisational structure, and are characterised by their unique identity, their name and descriptive properties. Each Organisation Cell contains at least one relationship to an Organisation Unit.

1.3	Abbreviations and Acronyms

OC:	Organisation Cell

OU:	Organisation Unit

1.4	Description

1.4.1.	General Introduction

Organisation Cells describe the formal, hierarchical structure of an enterprise. The organisational area, that is depicted by an Organisation Cell, can be of very different size (e.g., the whole enterprise, a department, a section or just the union of some jobs).

As such they can represent any entity identified at any level of the organisation hierarchy. The Organisation Cell construct provides both the identification of its contents and its position in the hierarchy. Cell content is recognised by naming its assigned  members (Organisation Units). Position in the hierarchy is represented by the definition of the assignments of lower level cells to the current cell and its own assignment to higher level cells. The CIMOSA construct enables multidimensional organisation structures (e.g. Matrix organisations, Network organisations, others) by allowing relations to multiple higher level cells.

Organisation Cells must have a unique identity, meaning that no two identical Organisation Cells can exist at any time. The relationships among Organisation Cells and their sub- or super-types are described as relational properties.

Identification of responsibilities and authorisation on different items (Function, Information, Resource) provides the link to other CIMOSA model views. These links will be used as escape mechanisms by identifying the organisation entity which has to take actions in case of unforeseen situations. Such situations may occur in model engineering as well as in its operational use. Through these links CIMOSA enables unambiguous assignments of responsibilities and authorisation on all enterprise entities (processes, information, resources and organisation) their assignment to organisation entities down to individual members (organisation units).

Design Authority identifies the entity responsible for the engineering of a particular construct or a set of constructs. Any change or modification of these constructs has to be authorised by the assigned entity. Operational Authority/Responsibility relates to decisions to be made in the course of using the model in operational tasks (e.g. decision support, model driven operation control and monitoring). Correction on the model itself have to deferred to model engineering and falls under the Design Authority mentioned above.

1.5	Description Template

Organisation Cells of all types are described by the following template.

ORGANISATION CELL

Header
Type: Name: Identifier: Design Authority:	[relevant type - select from list] [name of Organisation Cell in the form: <adjective> <noun>:      <adjective> qualifying the Organisation Cell      <noun> related to the scope of the Organisation Cell] [OC-<Unique Identifier>] [list of <identifier>/<name> of Organisation Unit and/or Organisation Cell]
Body
A. Descriptional Properties: CELL DESCRIPTION: OPERATIONAL AUTHORITY/RESPONSIBILITY:    Process Authorities/Responsibilities:    Information Authorities/Responsibilities:    Resource Authorities/Responsibilities: ORGANISATION LEVEL: B. Relational Properties: ASSIGNED ORGANISATION CELLS/UNITS: ASSIGNED TO ORGANISATION CELLS:	[textual description of the purpose of the Organisation  Cell] <identifier>/<name> of Organisation Unit authorised and responsible for the Organisation Cell. Must be a person. [NIL or list of <identifier>/<name> of Function View constructs (Domains, Domain Processes, Business Processes, Enterprise Activities, Events) on which this Organisation Cell has responsibility and authority] [NIL or list of <identifier>/<name> of Information View constructs (Enterprise Objects, Object Views, on which this Organisation Cell has responsibility and authority] [NIL or list of <identifier>/<name> of Resource View constructs (Functional Entities, Resource Sets or Resource Cells) on which this Organisation Cell has responsibility and authority] [Level of this Organisation Cell in relation to the organisation  hierarchy] [list of <identifier>/<name> of Organisation Units or Organisation Cells being part of this Organisation Cell] [NIL or list of <identifier>/<name> of the Organisation Cells which have responsibility and authority on this Organisation Cell]
Remark: The Operational Responsibility/Authorisation entry provides the identification of the person responsible for the Organisation Cell. It must be a person. It is one of the Organisation Units assigned to this Organisation Cell.

2.	Background Section

2.1	Examples

This Organisation Cell description defines the head of the Profit Center Standard/Variants of a gearbox manufacturing company.

ORGANISATION CELL

Header
Type: Identifier: Name: Design Authority:	Organisation Cell OC-007 'Profit Center s/v' OC-1 'Board of directors'
Body
A.  Descriptional Properties: CELL DESCRIPTION: OPERATIONAL AUTHORITY/RESPONSIBILITY:     Process Authorities/Responsibilities:     Information Authorities/Responsibilities:    Resource Authorities/Responsibilities:  ORGANISATION LEVEL:  B.  Relational Properties: ASSIGNED ORGANISATION UNITS:  ASSIGNED TO ORGANISATION CELLS:	The scope of this Organisation Cell is the production of mechanical parts (standards and variants). OU-06 'Jim Brown', 'Leader of Profit Center s/v' manufacturing process of standard products and variants staff data, construction data, manufacturing know how Production facilities and annual budget of the Profit Center s/v Second level of hierarchy OU-06 'Leader of Profit Center s/v', others tbd OC-01 'Production Management'
2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Organisation Unit
CIMOSA Technical Baseline

Organisation Unit

B41-2200. Version: 1.2; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Provides a representation of organisational objects of manufacturing enterprises. Describes the construct of the Requirements Definition Modelling Level the specification of the different jobs.

1.2	Terms and Definitions

(1)	Organisation Units: is the representation of  a job description (position). It is directly related to an Organisation Cell by exactly one relationship.

1.3	Abbreviations and Acronyms

OC:	Organisation Cell

OU:	Organisation Unit

1.4	Description

1.4.1.	General Introduction

Organisation Units describe the jobs within a given hierarchical structure of an enterprise. However this only relates to the organisational aspect of the job, those tasks which have to be done in relations to the responsibilities and authorities assigned to the particular Organisation Unit. The construct enables listing of the requirements in terms of the Skill Profile needed to serve the assigned task. These tasks may be both in the model engineering and the operational environment of the enterprise. For the latter tasks the assignments may not become known until system design has progressed to a rather advanced state. Therefore those requirements have to be gathered during the design phase demonstrating the iterativity of the model engineering process.

The Organisation Unit may be modelled as one or several Functional Entities in performing certain tasks in the enterprise operation. These roles will also be identified in this modelling construct.

Design Authority identifies the entity responsible for the engineering of a particular construct or a set of constructs. Any change or modification of these constructs has to be authorised by the assigned entity. Operational Authority/Responsibility relates to decisions to be made in the course of using the model in operational tasks (e.g. decision support, model driven control and monitoring). Correction on the model itself have to deferred to model engineering and falls under the Design Authority mentioned above.

Organisation Units must have a unique identity, meaning that no two identical Organisation Units can exist at any time. The relationships among Organisation Units and their sub- or super-types are described as relational properties. Management positions are indicated in the specific Organisation Cell.

1.5	Description Template

Organisation Units of all types are described by the following template.

ORGANISATION UNIT

Header
Type: Identifier: Name: Design Authority:	[relevant type - select from list] [OU-<Unique Identifier>] [name of Organisation Unit in the form: <adjective> <noun> <adjective> qualifying the Organisation Unit <noun> related to the scope of the Organisation Unit]  [list of <identifier>/<name> of Organisation Unit and/or Organisation Cell]
Body
A. Descriptional Properties: UNIT JOB DESCRIPTION: SKILL PROFILE: RESPONSIBILITIES: AUTHORITIES: FUNCTIONAL ENTITY: B. Relational Properties: ASSIGNED TO ORGANISATION CELL:	[textual description of decision-making or problem-solving tasks] [list of capabilities/skills which are needed to fulfil the job] [list of <identifier>/<name> of responsibilities given to this Organisation Unit] [list of <identifier>/<name> of authorities necessary to fulfil the job] [list of <identifier>/<name> of Functional Entity associated to this Organisation Unit] [<identifier>/<name> of the Organisation Cell which has responsibility and authority on this Organisation Unit]
2.	Background Section

2.1	Examples

This Organisation Unit description defines the job of the leader of the Profit Center Standard/Variants of a gearbox manufacturing company.

ORGANISATION UNIT

Header
Type: Identifier: Name: Design Authority:	Organisation Unit/Management OU-001 'Leader of Profit Center s/v' OC-1 'Board of Directors'
Body
A. Descriptional Properties: UNIT JOB DESCRIPTION: SKILL PROFILE: RESPONSIBILITIES: AUTHORITIES: FUNCTIONAL ENTITY: B. Relational Properties: ASSIGNED TO ORGANISATION CELL:	job description of the leader of the Profit Center standard/variants Leader of Profit Center, Trainer of collaborators success of Profit Center organisational authority for all collaborators tbd OC-007 Profit Center s/v
2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Organisation Element
CIMOSA Technical Baseline

Organisation Element

B41-2210. Version: 1.2; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Describes an individual piece of organisational data, forming the smallest decomposition item of the organisation at the Requirements Definition Modelling Level.

1.2	Terms and Definitions

(1)	Organisation Elements: are components of the constructs used at the Requirements Definition Modelling Level to represent organisation items which, for the purpose they are used, are indivisible.

1.3	Abbreviations and Acronyms (none)

1.4	Description

1.4.1.	General Definition

An Organisation Element is an indivisible or atomic item of an organisation and represents the lowest level of granularity of modelling in the CIMOSA Organisation View Requirements Definition Modelling Level. These Elements can be defined by the user according to his needs. At least, the following types are identified:

-	Responsibility

-	Authority

-	Decision Level

-	Skill Profile

Organisation Elements are used to describe properties of Organisation Units.

1.4.2.	General Constraints

-	The instantiation of Organisation Elements at the Partial and Particular Requirements Definition Modelling Level is constrained by the defined Instantiation Rules (described in the D-series Items).

-	Only meaningful Organisation Elements with a concrete reality for the Organisation must be defined in the Organisation view.

1.5	Description Template (not applicable)

2.	Background Section

2.1	Examples (none)

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Organisational Guidelines and Constraints
 CIMOSA Technical Baseline

Organisational Guidelines and Constraints

B41-3100. Version: 0.4; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Defines a construct to represent guidelines and constraints at different modelling levels of the Organisation View.

1.2	Terms and Definitions

(1)	Organisational Guidelines: describe a broad outline of the ideas on how to structure the organisation of an enterprise.

(2)	Organisational Constraints: describe restrictions imposed on the structure of the organisation of an enterprise.

1.3	Abbreviations and Acronyms (none)

1.4	Description

Organisational Guidelines

The organisation of a company has to be designed in a way that it reflects the strategic goals, supports the functional needs and matches the cultural particularities of the company.

Organisational Constraints

Organisational Constraints are needed to specify predefined conditions for the enterprise organisation. Such predefined conditions must be taken into consideration by the modelling process.

1.5	Description Template (optional)

Organisational Guidelines/Constraints are described bye the following template:

ORGANISATIONAL GUIDELINES/CONSTRAINTS

Header
Identifier: Name: Design Authority:	[OG/C-<unique identifier> [name of Organisational guideline/ constraint in the form: <adjective> <noun>, where <noun> relates to functionality, <adjective> relates to the scope] [list of  Organisational Object Views and/or Organisational Elements (defined in the Organisation View) in the form of <identifier>/<name>]
Body
A. Descriptional Properties:  Guideline/Constraint: B. Relational Properties:	[non-empty structured textual description of the objectives and constraints to be fulfilled by the organisational structure of the Organisation View]
2.	Background Section

2.1	Examples

The Organisational Guidelines are the basic conditions that will form the boundary of the organisational design of the enterprise. Depending on the complexity of those Organisational Guidelines, there will be more or less degree of freedom left within those boundaries for the particular organisational design. For clarification, the following three examples of Organisational Guidelines are provided.

2.1.1.	Examples 1: Number of Hierarchical Levels

Enterprise organisations will be heavily influenced by the management hierarchy and the number of levels implemented. Such an Organisational Guideline controls decentralisation and delegation of power in the organisation. The fewer hierarchical levels the larger the span of control on each level and the degree of autonomy.

Header
Identifier: Name: Design Authority:	OG/C-01 'Limited Levels of Hierarchy' OC-2 'Managing Board'
Body
A. Descriptional Properties:  Guideline/Constraint: B. Relational Properties:	The number of management levels will be restricted to 3. The span of control on each management level will be increased accordingly (not to exceed 15).
2.1.2.	Example 2: Customer Focus

Enterprise organisations may be influenced by explicit customer relations. Such an Organisational Guideline may require a matrix organisation type

Header
Identifier: Name: Design Authority	OG/C-02 'Customer Focus' OC-2 'Management Board'
Body
A. Descriptional Properties:  Guideline/Constraint: B. Relational Properties:	Every Customer has to have only one contact-person in the enterprise.
2.1.2.	Example 3: Process Orientation

Process oriented enterprise organisations may either fully replace functional organisation or may coexsist with the latter leading to matrix organisation type

Header
Identifier: Name: Design Authority:	OG/C-03 Process Orientation' OC-2 'Management Board'
Body
A. Descriptional Properties:  Guideline/Constraint: B. Relational Properties	Authority of operation has to be assigned to the Organisational Unit responsible for the operational processes.
2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Function View, Design Specification Modelling Level
CIMOSA Technical Baseline

Function View,

Design Specification Modelling Level

B12-1000. Version: 3.2; Last Update: 94.02.02

1.	Technical Section

1.1	Purpose and Scope

Provides the Function View constructs at the Design Specification Modelling Level and their relationships as perceived by the CIM system designer.

1.2	Terms and Definitions

(1)	Function View, Design Specification Modelling Level:

(a)	is the Function View of the Design Specification Modelling Level as defined in the European Pre-norm (ENV 40 003).

(b)	consists-of:

-	non-empty-set-of Generic Building Blocks and set-of Building Block Types for design specification in the Function View and

-	set-of Partial Design Specification Models for the Function View and

-	one Particular Design Specification Model for the Function View.

1.3	Abbreviations and Acronyms

CEN:	Comité Européen de Normalisation

ENV:	European Norm

1.4	Description

The Function View of the Design Specification Model describes how a set of structured resources (defined in the Resource View) is employed to meet the needs expressed in the Requirements Definition Model. Therefore, the derivation of the Function View of the Requirement Definition Modelling Level into the Function View of the Design Specification Modelling Level is not independent from the Resource View.

The purpose of the Function View at the Design Specification Modelling Level is to:

-	improve the consistency and completeness of the business user requirements; remove any ambiguity;

-	transform the functional user requirements into an implementable solution;

-	specify the necessary operations for each enterprise activity to be implemented;

-	test and investigate several potential solutions using computer simulation of the model;

-	obtain a consistent and optimised design model.

The Function View of the Particular Design Specification Model logically describes the desired realisation(s) of the Function View of the Particular Requirements Definition Model. After the selection of a particular solution, it contains the specifications of the system to be implemented in order to realise the defined user requirements. The CIMOSA Function View is described by means of Function View Modelling Paradigms.

The Design Specification Modelling Level of the Function View is made of three sub-parts:

1.	The Generic Design Specification Building Blocks which form a structured catalogue of all Generic Building Blocks and Building Block Types of the Function View used for design specification;

2.	The Partial Design Specification Models which make up a structured catalogue of classified, (partially) instantiated aggregations of Function View generic constructs used to instantiate Particular Design Specification Models;

3.	The Particular Design Specification Model which contains all design specifications for the Function View of one individual enterprise.

While the Function View of the Requirements Definition Modelling Level only defines what has to be done in more or less details in terms of user-oriented constructs (chiefly Domains, Events, Domain Processes and Enterprise Activities), the Design Specification Modelling Level must restructure and expand the functional model to remove any inconsistencies, provide more details and result in a computer executable form of the model indicating how things can be implemented, but still leaving out a number of implementation issues (such as final selection of components, code generation of some programs, data storage locations, etc.). While the Requirements Definition Modelling Level only deals with the definition of the functional structure of the enterprise, the Design Specification Modelling Level must deal with:

-	time

-	occurrences of some enterprise constructs

-	dynamic behaviour of some constructs (data, activities, resources) in the form of state diagrams

-	interaction between processes of the enterprise (co-operation, co-ordination or synchronisation mode)

in order to:

-	fully specify enterprise functionality

-	define and analyse the enterprise state (behaviour)

-	analyse and predict system performance (qualitative and quantitative analysis)

-	provide support for computer simulation of part or totality of the Design Specification Model

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	ENV 40 003: Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling. CEN/CENELEC, 1990.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Generic Building Blocks of the Function View, Design Specification Modelling Level
CIMOSA Technical Baseline

Generic Building Blocks of the Function View,

Design Specification Modelling Level

B12-2000. Version: 3.3; Last Update: 96.03.01

1.	Technical Section

1.1	Purpose and Scope

Provides the list of Generic Building Blocks of the Function View to be used in the CIMOSA Reference Architecture and the Particular Architecture for the specification of CIM system design.

1.2	Terms and Definitions

(1)	Generic Building Blocks of the Function View, Design Specification Modelling Level:

(a)	are used to build Partial Design Specification Models and Particular Design Specification Models.

(b)	set of Generic Building Blocks and Building Block Types of the Function View consists-of:

-	Objective/Constraint - O/C

-	Specified Domain - DM

-	Specified Domain Process - DP

-	Specified Business Process - BP

-	Specified Enterprise Activity - EA

-	Specified Event - EV

(c)	set of Generic Building Block components of the Function View consists-of:

-	Functional Operation - FO

-	Process Behaviour

-	Activity Behaviour

Note: Abbreviations are used in the templates for construct identification

1.3	Abbreviations and Acronyms

CEN: 	Comité Européen de Normalisation

ENV:	European pre-Norm

1.4	Description

Figure B12-2000/1: Generic Building Blocks of the Function View and their Relationship at the Design Specification Modelling Level

The CIMOSA Generic Building Blocks of the Function View at the Design Specification Modelling Level (see Figure B 12-2000/1) are used to build up the CIMOSA Function View Modelling Paradigm at this Modelling Level. In the Function View of the Design Specification Modelling Level CIMOSA describes in a precise, but still implementation independent, way what has to be done in the enterprise and how this could be done in terms of Specified Domains, Specified Domain Processes, Specified Business Processes and Specified Enterprise Activities. Furthermore, Specified Enterprise Activities have behaviour defined at this Modelling Level making use of Functional Operations. Functional Operations are the lowest level of granularity of functional modelling in CIMOSA. They are provided by Functional Entities (as described in the Resource View).

The behaviour of specified Domain Processes and Business Processes is defined as their Process Behaviour using a formal, implementation independent, computer processable language. The behaviour of specified enterprise Activities is defined as their Activity Behaviour (procedural control structure employing Functional Operations) by means of a formal, implementation independent, computer processable language. It is believed that the same language cannot be used for Process Behaviour and Activity Behaviour because they are not of the same nature.

Process Behaviour is concerned with control flow, i.e. defining triggering conditions to activate Business Processes and Enterprise Activities within a Domain Process. This is essentially based on values of Ending Statuses of Enterprise Activities and Business Processes, occurrences of Events and time. Operators on processes and activities in this language are sequential control, parallel branching, rendezvous, fork operator and choice operator as defined in process models [1, 2].

Activity Behaviour specifies the algorithm describing the way Functional Operations must be executed to realise the functionality of an Enterprise Activity. This is close a strongly typed procedural programming language and requires the handling of variables. Assignment, if-then-else, do-loop and other classical statements are required, including pre- and post-conditions.

Important Remark: Distinction between these two types of languages is fundamental in CIMOSA because it ensures clear separation of function and control (one of the fundamental CIMOSA principles).

Objective/Constraint is a common Generic Building Block defined in the B1-series of items. All other constructs of the Function View at this modelling level inherit properties from their equivalent definition in the Requirements Definition Modelling Level.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	Milner R. A Calculus of Communicating Systems. Lecture Notes 92. Springer-Verlag, Berlin. 1980.

2. 	Hoare C.A.R. Communicating Sequential Processes. Prentice-Hall, Englewood Cliffs, NJ. 1985.

3.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

4.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Specified Domain
CIMOSA Technical Baseline

Specified Domain

B12-2100. Version: 1.4; Last Update: 96.03.01

1.	Technical Section

1.1	Purpose and Scope

Provides the consistent and minimum set of information for the specification of Domains.

1.2	Terms and Definitions

(1)	Specified Domain:

(a)	is the description of a CIMOSA Domain in the Function View of the Design Specification Model. This construct provides a "Table of Contents" for the part of the enterprise being analysed, providing the list of specified constructs making up the Domain for the purpose of model design, simulation and validation.

(b)	is a construct inherited from the Requirements Definition Model used to establish the content and the boundary of the part of the enterprise which is subject to CIMOSA analysis based on a given set of business objectives and constraints (Domain Objective and Domain Constraint). It is made of a set of interacting Specified Domain Processes, Specified Events and Specified Object Views (information objects and physical objects including resources).

1.3	Abbreviations and Acronyms

RDM: 	Requirements Definition Model

DM:	Domain

DP:	Domain Process

EV:	Event

OC:	Organisation Cell

O/C:	Objective/Constraint

OV:	Object View

OU:	Organisation Unit

RL:	Domain Relationship

1.4	Description

A Specified Domain is the representation of a CIMOSA Domain in the Function View of the Design Specification Model. A Design Specification Model can be made of several Specified Domains. Each Specified Domain is derived from the Domain definition expressed at the Requirements Definition Modelling Level. However, only bottom level Domains are considered at this modelling level (i.e. sub-domains are not allowed).

Each Specified Domain must contain at least one Specified Domain Process and receive (and possibly send) at least one Specified Event. (A Domain is not allowed to exist as a closed world). At least one Specified Domain Process of a Specified Domain must be triggered by a Specified Event external to that Domain.

Since at the Design Specification Modelling Level global variables (represented by Specified Object Views) as well as messages (strings of bytes) can be exchanged by Specified Enterprise Activities, the Specified Domain is used to define the context of a well-defined set of Domain Processes and it allows the declaration of:

-	Specified Domain Processes used

-	Specified Events required by the Process Behaviour of Specified Domain Processes or created by Specified Enterprise Activities

-	Specified Object Views handled (and manipulated as global data structures)

-	Constants and data types of variables to be used in Activity Behaviour of Specified Enterprise Activities

-	Messages and communication channels for synchronisation among Specified Enterprise Activities (e.g. hand-shaking).

Once declared in the Domain definition, these declarations can be used in component construct of the Domain. They behave as global declarations in a programming language.

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Specified Domain instances of all types are described by the following template:

SPECIFIED DOMAIN (*)

Header
Type: Identifier: Name: Design Authority:	[relevant category - select from list; inherited from Domain definition in RDM] [DM-<unique identifier>; inherited from RDM] [name of Specified Domain in the form: <adjective> <noun>, where <noun> relates to the functionality, <adjective> relates to the scope; RDM] [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance; RDM]
Body
A. Descriptional Properties: DOMAIN OBJECTIVES: DOMAIN CONSTRAINTS: DOMAIN PROCESSES: OBJECT VIEWS: B. Relational Properties: BOUNDARY: EVENTS:	[non-empty list of <identifier> / <name> of Objective/ Constraint; RDM] ['NIL' or list of <identifier> / <name> of Objective/ Constraint; RDM] [non-empty list of <identifier> / <name> of Specified Domain Process instances possessed by this Specified Domain instance; RDM] [non-empty list of <identifier> / <name> of Specified Object View instances, occurrences are received, used or sent by this Specified Domain; RDM] [non-empty list of <identifier> / <name> of Domain Relationship instances between this Domain instance and other Domain instances. Can be left empty for partial instances] [non-empty list of <identifier> / <name> of Specified Event instances received or sent by this Specified Domain instance; RDM]
2.	Background Section

2.1	Examples

SPECIFIED DOMAIN

Header
Type: Identifier: Name: Design Authority:	Shop-Floor Operations/Batch-oriented DM-01 'Flexible Manufacturing Shop' OC-001 'Manufacturing Engineering'
Body
A. Descriptional Properties: DOMAIN DESCRIPTION: CIMOSA COMPLIANT: DOMAIN COMPONENTS DOMAIN OBJECTIVES: DOMAIN CONSTRAINTS: DOMAIN PROCESSES: OBJECT VIEWS: B. Relational Properties: BOUNDARY: EVENTS:	'Flexible Manufacturing Shop': Domain assigned to the Production of batches of parts with a medium degree of commonality (cylindrical shape, hard material), employing a set of metalworking machines and similar processing. yes O/C-01 'Objective of Flexibility' O/C-02 'Objective of Cycle-Time' O/C-11 'Constraint on Resources' DP-01 'Order Management' DP-02 'Exception Management' OV-001 'Workstation' OV-002 'Manufacturing Order' RL-01 'Order Release' RL-02 'Shop Condition' EV-01 'Order Management Request' EV-02 'Machine Failure'
2.2	Document References (none)

2.3	Open Issues (none)

(*)	Part of Header and Body inherited from RDM Level

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Specified Domain Process
CIMOSA Technical Baseline

Specified Domain Process

B12-2200. Version: 1.4; Last Update: 96.03.01

1.	Technical Section

1.1	Purpose and Scope

Specified a consistent piece of behaviour as one whole.

1.2	Terms and Definitions

(1)	Specified Domain Process:

(a)	is a modelling construct used to represent a Domain Process as it stands at the top of a functional decomposition within a Specified Domain of the Design Specification Model. Its set of Behavioural Rules (*) is described in terms of a Process Behaviour specification..

(b)	is a construct inherited from the Requirements Definition Model triggered by means of at least one Specified Event and nothing else than Events and producing defined end results (Function Output). It encapsulates a well-defined set of enterprise functionalities and behaviour (i.e. Functional Operation, Specified Enterprise Activity and Specified Business Process) to realise clearly defined objectives (Objective/Constraint).

(c)	receives input from and/or provides output to other Specified Domain Processes defined as Specified Object Views. It is only used by one Specified Domain, i.e. it is not used either by any other Specified Domain or a Specified Business Process, and therefore is at the top of a functional decomposition hierarchy.

1.3	Abbreviations and Acronyms

RDM: 	Requirements Definition Model

BP:	Business Process

DM:	Domain

DP:	Domain Process

DR:	Declarative Rule

EV:	Event

ES:	Ending Status

O/C:	Objective/Constraint

OC:	Organisation Cell

OV:	Object View

RE:	Resource

1.4	Description

Specified Domain Processes are Domain Process descriptions in the Function View of the Design Specification Model. Specified Domain Processes are stand-alone processes which specify a part of the Domain by encapsulating well-defined pieces of enterprise behaviour (Specified Business Processes) with enterprise functionalities (Specified Enterprise Activities) to achieve some Domain Objectives (as expressed in the Requirements Definition Model). Their occurrences must be triggered by means of occurrences of Specified Events internal or external to the Domain (and nothing but Events). Thus they represent entry points indicating where to start the execution of a particular model according to real-world events.

At least one Specified Domain Process instance must be triggered by means of an external Specified Event instance of the Domain instance. They inherit properties from the Requirements Definition Modelling Level and adds further properties. Compared to a Domain Process description as provided in the Requirements Definition Model, a Specified Domain Process instance description requires:

-	the list of Specified Event instances which are used to trigger this Specified Domain Process instance

-	a Structural Part,

-	a Process Behaviour (set of Behavioural Rules)

-	resource requirements

The set of Behavioural Rules of each Specified Domain Process instance is restructured at the design level and becomes the Process Behaviour. The Behavioural Rules are specified at the Design Specification Modelling Level according to a special computer processable syntax which can be used for computer simulation. This syntax is defined in Process Behaviour. It is slightly more sophisticated than the syntax of Behavioural Rules used at the Requirements Definition Modelling Level. A priority (number between 1 and 6) is provided to each Domain Process to solve process conflicts in accessing resources. When two processes with the same priority compete, the first-come is first-served. This priority (given by users) is inherited by employed Business Processes and Enterprise Activities.

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Specified Domain Process instances of all types are described by the following template:

SPECIFIED DOMAIN PROCESS (**)

Header
Type: Identifier: Name: Design Authority: Operation Responsibility: Operation Authority:	[relevant category - select from list <name>; inherited from RDM] [DP-<Unique Identifier>; RDM] [name of Domain Process instance in the form: <adjective> <noun>  <adjective>: qualifying the Domain Process instance  <noun>: related to the scope of the Domain Process; RDM] [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance. RDM] [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with responsibility for operation of this instance; new entry (***)] [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with authority for operation of this instance; new entry]
Body
A. Descriptional Properties: OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION: INPUTS    FUNCTION INPUT:    CONTROL INPUT:    RESOURCE INPUT: OUTPUTS    FUNCTION OUTPUT:    CONTROL OUTPUT:    RESOURCE OUTPUT: PROCESS BEHAVIOUR: PRIORITY: B. Relational Properties: WHERE USED: COMPRISES: EVENTS:	[non-empty list of  <identifier> / <name> of Objective/ Constraint; RDM ] ['NIL' or list of <identifier> / <name> of Objective/ Constraint; RDM ] ['NIL' or list of <identifier> / <name> of Declarative Rule instances applicable to this Domain Process instance;] [textual description; RDM] 'NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Specified Object View instances, occurrences of which are processed by activities of the process; RDM] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Specified Object View instances, occurrences of which are used but not processed by activities of this process; RDM] ['NIL' or list of <identifier> / <name> of Resource instances, occurrences of which are required for the full duration of occurrences of this Domain Process instance; new entry] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Specified Object View instances, occurrences of which are produced by activities of this process; RDM] ['NIL' or list of <identifier> / <name> of Specified Event instances, occurrences of which could be generated during the course of occurrences of this Specified Domain Process instance; RDM] ['NIL' or list of <identifier> / <name> of Specified Object View instances, which could be generated during the course of occurrences of this Domain Process instance; RDM] [non-empty set of Behavioural Rules expressed using the syntax defined for Process Behaviour; RDM] [Integer between 1 and 6 (1: lowest priority; 6: highest priority). By default, 6; new entry] [<identifier> / <name> of the Specified Domain employing this Specified Domain Process instance; RDM] [non-empty list of <identifier> / <name> of all next lower level enterprise functions (Specified Business Process and Specified Enterprise Activity instances) that are employed by this Specified Domain Process instance; RDM] [non-empty list of <identifier> / <name> of Specified Event instances, occurrences of which are required to trigger occurrences of this Specified Domain Process instance or used within the Domain Process instance; RDM]
2.	Background Section

2.1	Examples

SPECIFIED DOMAIN PROCESS (**)

Header
Type: Identifier: Name: Design Authority: Operation Responsibility: Operation Authority:	Manufacturing Operation/Batch Oriented DP-5 'Gearbox Assembly' OC-001 'Manufacturing Engineering' OC-007 'Profit Center s/v' OC-007 'Profit Center s/v'
Body
A. Descriptional Properties: OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION: INPUTS    FUNCTION INPUT:    CONTROL INPUT:    RESOURCE INPUT: OUTPUTS    FUNCTION OUTPUT:    CONTROL OUTPUT:    RESOURCE OUTPUT: PROCESS BEHAVIOUR: PRIORITY: B. Relational Properties: WHERE USED: COMPRISES: EVENTS:	O/C-90 'Grant Production Plan at Gearbox Assembly Level O/C-91 'Constraint of Resources and Cost DR-90 'Balance Gearbox Assembly Line between Push and Pull Concept DP-5-'Gearbox Assembly' models the assembly area for gearbox production consisting of the technological production system and the  production management system. OV-090 'Part' (Purchased parts, components and Sub-assemblies) OV-091 'Status information - old' RE-18 'Assembly Line' OV-092 'Gearbox' (Finished product) OV-093 'Manufacturing Order' (pull) OV-094 'Status information - new' NIL WHEN (START WITH Event EV-44 'Gearbox Assembly Order') DO BP-5.1 & BP-5.2 & BP-5.3 & BP-5.4 & BP-5.5 WHEN (ES(BP-5.1)= 'Case Completed') AND (ES(BP-5.2)= 'Differential Completed') AND (ES(BP-5.3)= 'MShaft Completed') AND (ES(BP-5.4)= 'AShaft Completed') AND (ES(BP-5.5)= Kit Completed') DO BP-5.6 WHEN (ES(BP-5.6)= 'Final Assembly Completed') DO FINISH (*issue Event-45*) WHEN (ES(BP-5.x)= 'not Completed') DO 'Exception Handling'  (*issue Event-25*) 6 (1: lowest priority; 6: highest priority). DM-1 'Gearbox Production' BP-5.1 'Case, Produce by Line' BP-5.4 'AShaft, Produce by Line BP-5.2 'Diff, Produce by Line' BP-5.5 'Kit, Produce by Line BP-5.3 'Mshaft, Produce by Line' BP-5.6 'Gearbox Final Assembly' EV-44 'Order' from DP-4 'Component Storage' EV-45 'Order' to DP-6 'Deliver Product' EV-25 'Request for 'Exception Handling'
2.2	Document References (none)

2.3	Open Issues (none)

(*)	Previously called Procedural Rule; renamed to avoid inconsistency with public meaning of term Procedural Rule.

(**)	Part of Header and Body inherited from RDM Level

(***)	Header and Body additional entries at DSM Level

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Specified Business Process
CIMOSA Technical Baseline

Specified Business Process

B12-2300. Version: 1.4; Last Update: 96.03.01

1.	Technical Section

1.1	Purpose and Scope

Describes a consistent and minimum set of information for the specification of Business Processes. Is used to structure Specified Business Processes and/or Specified Enterprise Activities.

1.2	Terms and Definitions

(1)	Specified Business Process:

(a)	is a modelling construct inherited from the Requirements Definition Model used to represent a Business Process within a Design Specification Model. It may have Resource Input and its set of Behavioural Rules (*) is described in terms of a Process Behaviour specification.

(b)	may have a functional part defined, and must have a behaviour part and a structure part. It is employed by one or more Domain Processes and/or Business Processes and it employs one or more Business Processes and/or Specified Enterprise Activity(ies). It is triggered by a parent structure (Specified Domain Process or Business Process).

1.3	Abbreviations and Acronyms

NC: 	Numerical Control

BP:	Business Process

DP:	Domain Process

DR:	Declarative Rule

ES:	Ending Status

RDM: 	Requirements Definition Model

O/C:	Objective/Constraint

OC:	Organisation Cell

OV:	Object View

RE:	Resource

1.4	Description

1.4.1	Generalities

Specified Business Processes are Business Process descriptions in the Function View of the Design Specification Model. Specified Business Processes are used to cluster lower level processes (Specified Business Processes) possibly with activities (Specified Enterprise Activities). They are characterised by their set of Behavioural Rules in the form of a Process behaviour. Their occurrences are triggered by occurrences of employing Specified Domain Process instances or Specified Business Process instances. Compared to a Business Process description as provided in the Requirements Definition Model, a Specified Business Process description requires:

-	the list of all possible Ending Statuses for the process

-	a Functional Part specifying Resource Input, i.e. resource requirements, if any

-	the Structural Part and

-	the Process behaviour (set of Behavioural Rules).

The set of Behavioural Rules of each Specified Business Process instance is restructured at the design level and becomes the Process Behaviour. The Behavioural Rules are specified at the Design Specification Modelling Level according to a special computer processable syntax which can be used for computer simulation. This syntax is slightly more sophisticated than the syntax of Behavioural Rules used at the Requirements Definition Modelling Level. It is presented in the FRB item named Process Behaviour.(**)

1.4.2	Resource allocation at Business Process level

Important comment: The ultimate CIMOSA goal is to achieve maximum flexibility by postponing the allocation of resource to activities until execution time (late binding). Nevertheless, for operational reasons, users will also require the option to allocate specific resources to Enterprise Activities (or Business Processes as shown in the next paragraph) during system design (early binding). However, remember that this early binding is needed in CIMOSA Release 1 since the IIS services will not provide a resource manager function (which is necessary for late binding process), but will be an optional facility in next CIMOSA Releases. Usually Resource allocation is done at Enterprise Activity level (see item B12-2400 for further explanations). In some specific cases, a Business Process instance may require the allocation of a set of Resource Units for the full duration of each of its occurrences and according to the specified Capability Set as described in the Resource View. For example, if an NC-machine needs to be especially prepared for a sequence of Enterprise Activities, it should be allocated at Business Process level to guarantee that all Enterprise Activity occurrences of the Business Process occurrence are using the same resource. Since each manufacturing process will need its own set-up Enterprise Activity, it is not possible to share this NC-machine between two different manufacturing processes. It has to be assigned to one process during its whole duration. This optional facility must be used with care. It is constraint by coherence rules:

-	a Resource allocated by a Business Process should be allocated by at least two of its children (Business Process or Enterprise Activity),

-	the child processes or activities using Resources allocated to a Business Process should as much as possible be group together; the number of children which don't need the Resources allocated at Business Process level should be minimised.

1.4.3	Business Process Ending Status

The Ending Status of a Business Process is a logical function of Ending Statuses of its employed Business Processes and Enterprise Activities. The Ending Status value of a Business Process can also be provided by the control mechanism controlling the execution of the model in the case of an abnormal end of the process (process interruption).

For instance, if Business Process BP1 always finishes by Enterprise Activity EA1, the Ending Status of BP1 is the Ending Status of EA1. If Business Process BP1 finishes by either Enterprise Activity EA1 or Enterprise Activity EA2, then the Ending Status of BP1 is given by a combination (Ending Status of EA1 or Ending Status of EA2). If Business Process BP1 finishes by both EA1 and EA2, then the Ending Status of BP1 is given by the combination (Ending Status of EA1 and Ending Status of EA2). Furthermore, the list of all possible Ending Status values and their meaning must be provided for each Business Process instance. This list may be larger than the list defined at the Requirements Definition Model (since more details are added at the design level).

In fact, four basic kinds of situation can be encountered:

-	Business Process finishing by one Enterprise Activity (the Ending Status value of the Business Process is one of the Ending Status values of the Enterprise Activity)

-	Business Process finishing by n (n>1) exclusive Enterprise Activities (the Ending Status value of the Business Process is a value of the union set of the Ending Status values of each Enterprise Activity)

-	Business Process finishing by n (n>1) non-exclusive Enterprise Activities (the Ending Status value of the Business Process is one value of the set of factorial combinations of the Ending Status values of all Enterprise Activities). This kind of situation should be avoided as much as possible.

-	Business Process finishing by a rendezvous of n (n>1) Enterprise Activities (the Ending Status value of the Business Process is one of the logical conjunctions of values (AND operator) in all elements of the Cartesian product of the sets of Ending Status values of these Enterprise Activities)

All other types of situations can be defined using these principles recursively, i.e. replacing a term 'Enterprise Activity' by 'Business Process'.

Definition: Any Ending Status value is a 0-argument predicate.

Values of Ending Statuses are used in the Behavioural Rules of the Process Behaviour of the employing processes (Domain Processes or Business Processes) for branching conditions.

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Specified Business Process instances of all types are described by the following template:

SPECIFIED BUSINESS PROCESS (***)

Header
Type: Identifier: Name: Design Authority: Operation Responsibility: Operation Authority:	[relevant category - select from list <name>; inherited from RDM] [BP-<Unique Identifier>; RDM] [name of Business Process instance in the form: <adjective> <noun>  <adjective>: qualifying the Business Process instance  <noun>: related to the scope of the Business Process; RDM]  [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance; RDM] [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with responsibility for operation of this instance; new entry] [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with authority for operation of this instance; new entry]
Body
A. Descriptional Properties:  OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION: INPUTS    FUNCTION INPUT:    CONTROL INPUT:    RESOURCE INPUT: OUTPUTS    FUNCTION OUTPUT:    CONTROL OUTPUT:    RESOURCE OUTPUT: ENDING STATUSES: PROCESS BEHAVIOUR: B. Relational Properties: WHERE USED: COMPRISES:	[non-empty list of <identifier> / <name> of Objective/ Constraint; RDM] ['NIL' or list of <identifier> / <name> of Objective/ Constraint; RDM] ['NIL' or list of <identifier> / <name> of Declarative Rule instances applicable to this Business Process instance;] [textual description; RDM] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Specified Object View instances, occurrences of which are processed by activities of the process; RDM] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Specified Object View  instances, occurrences of which are used but not processed by activities of the process; RDM] ['NIL' or list of <identifier> / <name> of Resource instances, occurrences of which are required for the full duration of occurrences of this Business Process instance; new entry] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Specified Object View instances, occurrences of which are produced by activities of this process; RDM] ['NIL' or list of <identifier> / <name> of Specified Event instances, occurrences of which could be generated during the course of occurrences of this Business Process instance; RDM] ['NIL' or list of <identifier> / <name> of Specified Object View instances, which could be generated during the course of occurrences of this Business Process instance; RDM] [non-empty list of all possible values and their logical expression as a function of ending statuses of employed functionalities for occurrences of this Specified Business Process instance. They are declared as: <value> ":" <logical function>; RDM] [non-empty set of Behavioural Rules expressed using the syntax defined for Process Behaviour; RDM]  [non-empty list of <identifier> / <name> of Specified Domain Process and/or Business Process instances employing this Specified Business Process instance; RDM] [non-empty list of <identifier> / <name> of all next lower level Specified Business Process instances and Specified Enterprise Activity instances that are employed by this Specified Business Process instance; RDM]
2.	Background Section

2.1	Examples

SPECIFIED BUSINESS PROCESS

Header
Type: Identifier: Name: Design Authority: Operation Responsibility: Operation Authority:	Shop Floor Operation/Batch Oriented BP-5.1 'Case Completed' OC-001 'Manufacturing Engineering' OC-007 'Profit Center s/v' OC-007 'Profit Center s/v'
Body
A. Descriptional Properties:  OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION: INPUTS    FUNCTION INPUT:    CONTROL INPUT:    RESOURCE INPUT: OUTPUTS    FUNCTION OUTPUT:    CONTROL OUTPUT:    RESOURCE OUTPUT: PROCESS BEHAVIOUR: B. Relational Properties: WHERE USED: COMPRISES:	O/C-90 'Grant Production Plan at Case Assembly Level O/C-91 'Constraint of Resources and Cost NIL BP-5.1-'Case Completed' models the case assembly area for the gearbox production consisting of the technological production system. OV-095 'Part' (Purchased parts, components) OV-096 'Status information - old' RE-19 'Case Assembly Line' OV-096 'Case' (Subassembly) OV-097 'Manufacturing Order' (pull) OV-098 'Status information - new' NIL WHEN (START WITH Event EV-44 'Gearbox Assembly Order')  DO BP-5.1 WHEN (ES(BP-5.1)= 'Case Completed') DO BP-5.6 WHEN (ES(BP-5.1)= 'not Completed') DO 'Exception Handling'  (*issue Event-25*) DP-5 'Gearbox Assembly' tbd
2.2	Document References (none)

2.3	Open Issues (none)

(*)	Previously called Procedural Rule; renamed to avoid inconsistency with public meaning of term Procedural Rule.

(**)	Note: The state diagram associated to each Business Process instance and used at run-time is described in the C5-1110 item (BC Service Definition).

(***)	Part of Header and Body inherited from RDM Level

(****)	Header and Body additional entries at DSM Level

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Process Behaviour
CIMOSA Technical Baseline

Process Behaviour

B12-2310. Version: 1.3; Last Update: 96.03.01

1.	Technical Section

1.1	Purpose and Scope

Provides a language to specify Business Process and Domain Process behaviour (i.e. their set of Behavioural (*) Rules) at the Design Specification Modelling Level.

1.2	Terms and Definitions

(1)	Process Behaviour: represents the flow of control governing the behaviour of Specified Domain Processes or Specified Business Processes of the Design Specification Model. It is a declarative language made of a set condition-action rules for each process. The following set of condition-action rules has been defined:

-	process triggering

-	forced

-	conditional

-	spawning

-	rendezvous

-	looping

-	completion

-	run-time choice

-	unordered set

1.3	Abbreviations and Acronyms

IIS:	Integrating Infrastructure

1.4	Description

1.4.1	Generalities

Process Behaviour is the part of a specified process (Domain Process or Business Process) which describes how to control the execution of lower Business Processes and/or Enterprise Activities using their Ending Status values in the Function View of the Design Specification Model. It is derived from the description of Behavioural Rules of the associated process as defined at the Requirements Definition Modelling Level. It is made of a set of condition-action rules and therefore has a declarative flavour.

1.4.2	Process Behaviour Description

Process Behaviour is defined as an unordered set of declarative condition-action rules.

Important Remark: Only one rule in a Process Behaviour can be fired at any time.

Definition: A rule can be fired when its condition clause evaluates to true. Firing a rule results in the activation of actions specified in its action clause.

Each rule is defined by:

-	a condition clause and

-	an action clause

and has the following syntax:

WHEN <condition> DO <action>

The action is a Specified Business Process or a Specified Enterprise Activity. Sequence of actions are described by successive rules.

The syntax of Process Behaviour in Backus-Naur form is as follows:

<Process-Behaviour> ::= <Rule> | <Rule> <Rule-set>

<Rule> ::=  "WHEN" "(" <Condition-clause> ")" "DO" <Action-clause>

<Condition-clause> ::= <Cond> | <Cond> "AND" <Condition-clause>

<Cond> ::= "START" | "START" "WITH" <EventCond> | <CondExp>

<CondExp> ::= <exp> | <exp> "AND" <CondExp>

<exp> ::= "ES" "(" <Function-name> ")" "=" <value> | "ES" "(" <Function-name> ")" "=" "any" | <EventCond>

<EventCond> ::= <Event-name> | <Event-name> "AND" <EventCond>

<value> ::= string

<Action-clause> ::= <Function-name> | <Spawning> | <Choice> | "FINISH"

<Spawning> ::= <Function-name> "&" <Other-Spawning>

<Choice> ::= <Function-name> "|" <Other-Choice>

<Other-Spawning> ::= <Function-name> | <Function-name> "&" <Other-Spawning>

<Other-Choice> ::= <Function-name> | <Function-name> "|" <Other-Choice>

<Function-name> ::= identifier (* must be the identifier of a Business Process or of an Enterprise Activity *)

If proved necessary, the syntax of the condition clause could be significantly extended in the future to deal with variables in expressions of the clause. This is not done in the current version of CIMOSA to enforce the principle of separation of function and control.

2.	Background Section

2.1	Examples

Examples of valid rules are:

To start the set of rules of a Business Process:

WHEN (START) DO EA-1 & EA-2

To start a Domain Process by an Event:

WHEN (START WITH Event) DO BP-1

To start a Domain Process by a conjunction of two Events:

WHEN (START WITH Event 1 AND Event 2) DO BP-1

To wait for EA-1 with status "value1" to trigger BP-5

WHEN (ES (EA-1)) = value1 DO BP-5

To combine ending statuses and events to trigger a sequence of actions:

WHEN (ES (EA-1) AND ES (BP-3) AND Event 1) DO BP-6

To finish a set of rules:

WHEN (ES (EA-4) = value1) DO FINISH

To finish a set of rules whatever the Ending Status of EA-4 is:

WHEN (ES (EA-4) = any) DO FINISH

2.2	Document References (none)

2.3	Open Issues (none)

(*)	Previously called Procedural Rule; renamed to avoid inconsistency with public meaning of term Procedural Rule.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Specified Enterprise Activity
CIMOSA Technical Baseline

Specified Enterprise Activity

B12-2400. Version: 1.4; Last Update: 96.03.01

1.	Technical Section

1.1	Purpose and Scope

Describes the Specified Enterprise Activity concept at the Design Specification Modelling Level.

1.2	Terms and Definitions

(1)	Specified Enterprise Activity: is a modelling construct inherited from the Requirements Definition Model used to describe enterprise functionality within a Specified Domain as part of a Specified Domain Process (Specified Business Process) at the Design Specification Modelling Level. It is defined by its Function Input, Control Input, Resource Input, Function Output, Control Output, Resource Output, Ending Status and Activity Behaviour. The Activity Behaviour specification indicates how Functional Operations are employed to realise the functionality of the Enterprise Activity.

1.3	Abbreviations and Acronyms

RDM: 	Requirements Definition Model

CS:	Capability Set

DR:	Declarative Rule

EA:	Enterprise Activity

FE:	Functional Entity

OC:	Organisation Cell

O/C:	Objective/Constraint

OV:	Object View

OU:	Organisation Unit

1.4	Description

1.4.1	Generalities

A Specified Enterprise Activity is the specification of an Enterprise Activity in the Function View of the Design Specification Model. Each Specified Enterprise Activity instance describes a piece of enterprise functionality to be implemented as a program of work to achieve the required functionality defined at the Requirements Definition Modelling Level within one Domain.

In the Physical System of the enterprise, the specified activity can be executed by machines, humans, applications or a combination of these. They are covered by the generic term of Functional Entities.

Important Comment 1: In practice, the execution of Enterprise Activities requires acquisition of resources at run-time and time for the full duration of the activity.

Important Comment 2: The ultimate CIMOSA goal is to achieve maximum flexibility by postponing the allocation of resource to activities until execution time (late binding). Nevertheless, for operational reasons, users will also require the option to allocate specific resources to Enterprise Activities during system design (early binding). However, remember that this early binding is needed in CIMOSA Release 1 since the IIS services will not provide a resource manager function (which is necessary for late binding process), but will be an optional facility in next CIMOSA Releases.

As a program of work, a Specified Enterprise Activity can be further broken down into basic units of work, called Functional Operations, which need to be organised in a procedural and deterministic fashion. The Functional Operations are to be executed by Functional Entities (a subset of Resources defined in the Resource View). This decomposition of the activity should follow resource design and the establishment of a set of Functional Operations and is possibly an iterative process leading to an Enterprise Activity decomposition that is coherent with the resource design. When it is executed a Specified Enterprise Activity can be started, stopped, suspended and later resumed or finished. Thus it has a state diagram (described in item C5-1210 AC Service Definition) associated to it which has to be known and controlled by the model execution control mechanism.

1.4.2	Detailed Description

From the Function View modelling stand-point a Specified Enterprise Activity is composed of a finite set of Functional Operations connected to one another by a well-defined algorithm to produce the Activity Behaviour in order to realise a defined program of work. Each Functional Operation acts as a call to a Functional Entity in order to have a unit of work being performed. Any time that a Functional Operation needs to be executed by a Functional Entity, this unit of work must have been executed with success or failure and after execution a message is returned by the Functional Entity as one argument of the list of arguments of the Functional Operation so that the Enterprise Activity is made aware of the status of the Functional Operation execution (success or failure).

At the Design Specification Modelling Level a Specified Enterprise Activity has:

-	the list of the local variables used in the algorithm of the Activity Behaviour,

-	Function Input made of Object Views describing the objects needed and processed by the activity,

-	possibly Control Input made of Object Views describing information about run-time data or data used but not modified which influence the execution of the algorithm of Activity Behaviour

-	Resource Input providing the list of Resources to be used during the execution of occurrences of the activity

-	Function Output made of Object Views describing the objects produced by the activity. Nearly all of these objects become Function Input or Control Input or Resource input of other Enterprise Activities,

-	an Ending Status value indicating the termination status of the activity

-	possibly Resource Output made of one or more Object Views and defining the status of Resources after the execution of the Specified Enterprise Activity,

-	a list of parent constructs (Specified Domain and/or Business Processes) employing this Specified Enterprise Activity

Specified Object Views describing the Function Input, Control Input, Function Output and Resource Output of the Enterprise Activity instance are Object Views identified at the Requirements Definition Modelling Level.

Required Capability Sets defined in the Requirements Definition Model are used to match the Capability Sets provided by the Resources specified for the Enterprise Activity instance in the Design Specification Model.

Resource Input indicate the Resources to be used by the Specified Enterprise Activity. This is mandatory. The Resource Input must contain at least one Functional Entity.

Resource Output is optional. If it needs to specified it is made of one more Object Views defining information about the status of the Resources after the execution of the activity. This information is required for Resource Management. This can be useful in simulation analysis of the model.

Internal behaviour of the Specified Enterprise Activity instance is specified by an algorithm defining the Activity Behaviour. The syntax of the language to be used is given in the Activity Behaviour item. Some of the statements of this language allow for messages to be received or sent by Enterprise Activities to support interactions between Enterprise Activities of the same Domain Process. Parallel execution of sets of Functional Operations is also allowed.

Constraints and Declarative Rules defined on the Enterprise Activity at the requirements level must be respected by the specification of the Enterprise Activity. They are taken into account by the algorithm of Activity behaviour, and especially pre- and post-conditions of Activity Behaviour.

1.4.3	Ending Status of a Specified Enterprise Activity

Any Enterprise Activity has by definition a special variable attached to it and known by the supporting environment having to control its execution. This variable is called Ending_Status. This variable is used in the Process Behaviour of the processes employing the Enterprise Activity. Initialisation of this variable can be made in algorithm of the Specified Enterprise Activity itself within one of the statements of Activity Behaviour. Thus this variable does not have to be declared in the Specified Enterprise Activity and can be used freely in the pseudo-code of the algorithm of Activity Behaviour.

1.4.4	Synchronisation of and Communication Among Specified Enterprise Activities

Enterprise Activities of a same Domain or of different Domains of an enterprise are allowed to communicate by exchanging messages and events for synchronisation. The language used for Activity Behaviour allows the use of the following special functions defined as Functional Operations and which can be used as statements in the pseudo-code of the algorithm of Activity Behaviour:

1)	Generate Events: 'Generate' '(' <Event> ')'

where <Event> is the name of a CIMOSA Event. This function raises an event which is sent to the outside.

2)	Send Synchronisation Messages: 'Send' '(' <EA-name> ',' <message> ')'

where <EA-name> is the name of the Enterprise Activity to which a synchronisation message <message> needs to be sent.

3)	Receive Synchronisation Messages: 'Receive' '(' <EA-name> ',' <message> ')'

where <EA-name> is the name of the enterprise Activity from which a synchronisation message <message> is expected.

It can easily be seen that using these functions in the appropriate way, one can make:

-	two or more Enterprise Activities co-operate with one another

-	two or more Enterprise Activities be synchronised together (using a producer/consumer policy with acknowledgement)

-	two or more Enterprise Activities work in a asynchronous mode (no acknowledgement message)

Furthermore, Enterprise Activities can also be synchronised by their Function Input when one has to wait for input information sent by another one.

1.4.5	Time Data

Time can be associated to Enterprise Activity. Depending on the type of analysis to be made, time is associated to the duration of an activity. We can model:

-	the average duration of the activity

-	the maximum execution time of the activity

-	the minimum execution time of the activity

This information can be useful for simulation of the model or for quantitative analysis (for instance by timed Petri net techniques).

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Specified Enterprise Activity instances of all types are described by the following template:

SPECIFIED ENTERPRISE ACTIVITY (*)

Header
Type: Identifier: Name: Design Authority: Operation Responsibility: Operation Authority:	[relevant category - select from list <name>; inherited from RDM] [EA-<Unique Identifier>; RDM] [name of Enterprise Activity instance in the form: <adjective> <noun> <adjective>: qualifying the Enterprise Activity instance <noun>: related to the scope of the Enterprise Activity; RDM] [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance. RDM] [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with responsibility for operation of this instance; new entry (**)] [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with authority for operation of this instance; new entry]
Body
A. Descriptional Properties:  OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION: REQUIRED CAPABILITIES: INPUTS    FUNCTION INPUT:    CONTROL INPUT:    RESOURCE INPUT: OUTPUTS    FUNCTION OUTPUT:    CONTROL OUTPUT:    RESOURCE OUTPUT: ENDING STATUSES: ACTIVITY BEHAVIOUR: AVERAGE DURATION: MINIMUM DURATION: MAXIMUM DURATION: INPUT CHANNELS: OUTPUT CHANNELS: B. Relational Properties: WHERE USED: COMPRISES:	[non-empty list of <identifier> / <name> of Objective/ Constraint; RDM] ['NIL' or list of <identifier> / <name> of Objective/ Constraint; RDM] ['NIL' or list of <identifier> / <name> of Declarative Rule instances applicable to this Enterprise Activity instance; RDM] [textual description; RDM] ['NIL' or <identifier> / <name> of Capability Set defining required capabilities of occurrences of this Specified Enterprise Activity instance; RDM] [non-empty list of <identifier> / <name> of Specified Object View instances describing input information processed by the algorithm of this Specified Enterprise Activity instance; RDM] [list of <identifier> / <name> of Specified Object View instances describing input information providing run-time data used but not modified by occurrences of this Specified Enterprise Activity instance; RDM] [non-empty list of <identifier> / <name> of Specified Resource instances required by occurrences of this Specified Enterprise Activity instance; new entry] [non-empty list of <identifier> / <name> of Specified Object View instances describing the outputs produced by occurrences of the Specified Enterprise Activity instance; RDM] [list of <identifier> / <name> of Specified Event instances, occurrences of which can be generated by occurrences of this instance; RDM] [list of <identifier> / <name> of Specified Object View instances describing the status of Resources after the execution of occurrences of the Specified Enterprise Activity instance; RDM] [non-empty list of Ending Status values produced by occurrences of this Enterprise Activity instance and their signification in the form:  <value> : <signification> where <value> is mandatory and is a 0-argument predicate and  <signification> is optional and is text; RDM] [algorithm of the functionality defined using the language provided for Activity Behaviour; new entry] [average duration of occurrences of the Enterprise Activity instance; new entry] [minimum duration of occurrences of the Enterprise Activity instance; new entry] [maximum duration of occurrences of the Enterprise Activity instance; new entry] [list of channel names for input messages; new entry] [list of channel names for output messages; new entry] [list of <identifier> / <name> of Specified Domain Process and/or Specified Business Process employing this Specified Enterprise Activity; RDM] [list of Functional Operations employed by this Specified Enterprise Activity; new entry]
2.	Background Section

2.1	Examples

The Validate Customer Enterprise Activity needs as inputs the file of orders (Processable_Orders Object View) and the file of customers (Customer_Info Object View). It produces as outputs the updated customer file (New_Customer_Info Object View), the customer order records (Orders Object View), the invalid customer records (Invalid_Customers Object View) and the Customer_status message.

SPECIFIED ENTERPRISE ACTIVITY

Header
Type: Identifier: Name: Design Authority: Operation Responsibility Operation Authority:	Administrative/Accounting EA-21 'Validate Customer' OU-01 'J.P Smith', OC-004 'Accounting' OC-004 'Accounting' OC-004 'Accounting'
Body
A. Descriptional Properties:  OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION: REQUIRED CAPABILITIES: INPUTS    FUNCTION INPUT:    CONTROL INPUT:    RESOURCE INPUT: OUTPUTS    FUNCTION OUTPUT:    CONTROL OUTPUT:    RESOURCE OUTPUT: ACTIVITY BEHAVIOUR: ENDING STATUS: AVERAGE DURATION: MINIMUM DURATION: MAXIMUM DURATION: INPUT CHANNELS: OUTPUT CHANNELS: B. Relational Properties: WHERE USED: COMPRISES:	O/C-04 'Customer Acceptance' O/C-13 'Credit Limit' DR-1 'Customer Rejection Rule' This enterprise activity is used to check if a customer passing orders is a validate customer in the sense he should not have his credit limit over $ 5000. CS-11 'Validating Customer Capabilities' OV-003 'Processable Orders' OV-004 'Product Info OV-005 'Customer Info' FE-04 'Administrator' OV-006 'New Customer Info' OV-007 'Order' OV-008 'Product Request' OV-009 'Invalid Customer' NIL NIL {DECLARE Customer_status: integer; Order: Order; Customer: Customer PRE-CONDITIONS:  Not-empty (Processable_Orders);  Not-empty (Customer_Info) BEGIN (* Validate Customer *) SD.Open (Processable_Orders); FOREACH Order IN Processable_Orders DO SD.Select (Customer_Info, Order, Customer); PMG1.Check_Customer_Credit (Customer, Customer_status); IF Customer_status = OK THEN (* Valid customer *) PMG2.Create_New_Customer  (New_Customer_Info, Customer); PMG3.Collect_All_Orders (Customer, Orders); SD.Write (Orders); ELSE (* Invalid customer *) %.Display ("Customer status: ",Customer_status); %.Write ("Invalid Customer: ", Customer); END Ending_Status := "Validation Completed" END (* Validate Customer *); POST-CONDITIONS: Dispose (Customer_status, Order, Customer)} ES(EA-21) =  'Validation Completed': normal termination 'Incomplete Validation': abnormal termination 01:30 00:30 02:00 NIL NIL DP-03 'Customer Order Processing' FO-01 'Open' FO-04 'Check Customer Credit' FO-07 'Select' FO-02 'Select' FO-05 'Create New Customer' FO-03 'Write' FO-06 'Collect All Orders'
-	SD, PGM1, PGM2 and PGM3 are Functional Entities representing data services and applications.

-	% represents reference by default to a Functional Entity in a Functional Operation. (See Functional Operation item).

-	Processable_Orders, Customer_Info, New_Customer_Info are Specified Object Views. All other variables are local parameters.

-	The pre-conditions make sure that the input files are not empty. The post-condition frees the local variables used.

2.2	Document References (none)

2.3	Open Issues (none)

(*)	Part of Header and Body inherited from RDM Level

(**)	Header and Body additional entries at DSM Level

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Activity Behaviour
CIMOSA Technical Baseline

Activity Behaviour

B12-2410. Version: 1.1; Last Update: 94.01.14

1.	Technical Section

1.1	Purpose and Scope

Defines a procedural language used to specify the functionality of Enterprise Activities. Activity Behaviour is based on the use of the concept of Functional Operation. The language is computer processable.

1.2	Terms and Definitions

(1)	Activity Behaviour: defines the internal behaviour (or flow of control) of Specified Enterprise Activity(ies) of the Design Specification Model. It specifies how to perform the functionality of an Enterprise Activity in terms of an algorithm making use of Functional Operations.

1.3	Abbreviations and Acronyms (none)

1.4	Description

1.4.1	Generalities

Activity Behaviour of a Specified Enterprise Activity is an algorithm which describes how to control the execution of Functional Operations to perform a piece of functionality in the Design Specification Model.

1.4.2	Activity Behaviour Description

Activity Behaviour is defined by procedural control structures (an algorithm) expressed in pseudo-code form. The Activity Behaviour language has been influenced by ADA.

Activity Behaviour consists of four major declaration parts: preconditions, body and post conditions. The preconditions and post conditions parts are used to check the state of the system immediately before and immediately after the execution of the activity body. If the assertions of the preconditions and post conditions are false, the exception treatment specified in the <Actions> element is executed. Some preconditions and post conditions results from design choices; some others are derived from Declaratives Rules from Requirement Definition Modelling Level.

Activity Behaviour is defined by the following syntax in Backus-Naur form:

<Activity-Behaviour> ::= "{" <Declarations> <Preconditions> <Body> <Postconditions> "}"

<Declarations> ::= "DECLARE" <constants> <types> <variables>

<constants> :: = "CONST" <const-def> | NIL

<const-def> ::= <const> <const-def> | NIL

<const> ::= <cidentifier> "=" <c-value> ";"

<cidentifier> ::= identifier (Must be the identifier of a constant.)

<c-value> ::= <numeric-value> | <string-value>

<numeric-value> ::= <sign> <number> | <number>

<sign> ::= "+" | "-"

<number> ::= <digit> | <digit> <number>

<digit> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

<string-value> ::= "'" <s-value> "'"

<s-value> ::= <digit> <letters> | <letter> <letters>

<letters> ::= <letter> <letters> | <digit> <letters> | <symbol> <letters> | NIL

<letter> ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" |

 "T" | "U" | "V" | "X " | "Y" | "Z" | "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n"

| "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"

<symbol> ::= "-" | "+" | "*" | "=" | "_" | "!" | "#" | "$" | "%" | "&" | "(" | ")" | "," | ";" | ":" | "." | "?" | "/" | "\" | "|"

| "<" | ">" | "@" | "'" | "[" | "]" | "{" | "}" | "^" | "~" | """ | blank

<types> ::= "TYPES" <type-def-list> | NIL

<type-def-list> ::= <type-def> <type-def-list> | NIL

<type-def> ::= <type-id> "=" <type-cat> ";"

<type-id> ::= <tidentifier> | <tidentifier> "," <next-tidentifier>

<identifier> ::= identifier (Must be the identifier of a type.)

<type-cat> ::= <built-in-types> | <array> | <record> | <enumerated> | <constructed-types>

<built-in-types> ::= "INTEGER" | "REAL" | "BOOLEAN" | "CHAR" | "DATE" | "TIME" | "EXTTIME" |

"MONEY" | <string> | "FOstatus" | <file>

<file> ::= "FILE" "(" <number> ")"

This type allows a file to be considered as a data item to be handled with FTAM services of the Information Entity.

Different types of formatted files can be used according to the value of <number> where:

- 0 is used for ASCII files

- 1 is used for binary files

- 5 is used for IGES files

- 6 is used for STEP files

- 10 is used for CADAM files

- Other codes need to be defined.

DATE has the format: yyyy:mm:dd or yy:mm:dd where "yyyy" means year as a 4-digit number, "yy" means year as a 2-digit number, "mm" means month as a 1 or 2-digit number and "dd" means day as a 1 or 2-digit number.

TIME has the format: hh:mn:ss where "hh" means hour as a 1 or 2-digit number, "mn" means minute as a 1 or 2-digit number (max. is 60) and "ss" means second as a 1 or 2-digit number (max. is 60).

EXTTIME represents extended time, i.e. date and time.

MONEY represents amount of money (decimal part reduced to 2 digits).

FOstatus is an integer type reserved for Functional Operation termination statuses (must be the last argument in the parameter list of Functional Operations if used). 0 means successful termination, strictly positive values means successful termination under special conditions (defined by the user), and strictly  negative values mean unsuccessful termination under special conditions defined by the user.

<string> ::= "STRING" "[" <length> "]"

<length> ::= <number> | <cidentifier>

<array> ::= same as in standard Pascal [2]

<record> ::= same as in standard Pascal

<enumerated> ::= same as in standard Pascal

<constructed-types> ::= same as in standard Pascal

<variables> ::= "VAR" <var-list> | NIL (Used to declare local variables, including Implemented External Schemata.)

<var-list> ::= <var> | <var> ";" <var-list> | NIL

<var> ::= <var-names> ":" <type-name>

<var-names> ::= <var-name> | <var-name> "," <var-names>

<var-name> ::= identifier  (Must be the name of a variable.)

<type-name> ::= <tidentifier> | <esidentifier> (Must be a type identifier or an Implemented External Schema identifier.)

<Preconditions> ::= "PRE-CONDITIONS" <Predicate-List> | NIL

<Postconditions> ::= "POST-CONDITIONS" <Predicate-List> | NIL

<Predicate-List> ::= <Predicate> | <Predicate> ";" <Predicate-List>

<Predicate> ::= <predicate-name> | <predicate-name> "(" <arg-list> ")"

<predicate-name> ::= "Not_empty" | "Lock" | "Unlock" | <others>

<others> ::= to be defined

<Body> ::= "BEGIN" <Instructions> "END"

<Instructions> ::= <Instruction> | <Instruction> ";" <Instructions> | NIL

<Instruction> ::= <assignment> | <seqs> | <conds> | <case> | <while> | <until> | <for> | <foreach> | <parallel> | <FO-call>

1.4.3	Types of Control Structures

Types of control structures which can be used to specify Activity Behaviour are:

1)	Sequential Control:

<statement1> ';' <statement2> ';' ...';' <statementn>

where <statement1>, <statement2>, ..., <statementn> are statements.

2)	Conditional Control:

'if' <Boolean-expression> 'then' <statements> 'end'

or

'if' <Boolean-expression> 'then' <statements>

'else' <statements>

3)	Selective Control:

'case' <expression> 'of'

v1: <statements> ';'

v2: <statements> ';';

...

vn: <statements>

'else' <statements> 'end'

where <expression> may have its value among values v1, v2, ..., vn

4)	Iterative Control:

'while' <Boolean-expression> 'do' <statements> 'end'

or

'do' <statements> 'until' <Boolean-expression> 'end'

5)	Iterative Control conditioned by a set of values:

'foreach' <variable> 'in' <set> ['where' <Boolean-expression>]

'do' <statements> 'end'

where <variable> is the name of a parameter and <set> is a set of values which, for instance, it can be provided by an External Schema. The 'where' clause is optional.

This control structure is used whenever it is required to execute a sequence of instructions (<statements>) for each value of a parameter (<variable>) in the set (<set>) verifying the Boolean expression.

6)	Iterative Control conditioned by an interval

'for' <control-variable> ':=' <initial-value> 'to' <final-value> ['by' <step>] 'do' <statements> 'end'

where <control-variable> is a local parameter of the Enterprise Activity, the scalar values of which vary from <initial-value> to <final-value> by step <step>. The 'by' <step> clause is optional; default value of <step> is 1.

This control structure is used to repeat a processing for each value of an array structure.

7)	Control Structure for Parallel Execution

'cobegin' <statement1> '//' <statement2> '//' ...<statementn> 'coend'

This control structure allows parallel or concurrent execution of (possibly compound) statements with a join at the end.

8)	Statement Syntax Definition

All <statements> in the previous control structures are defined by:

<statements> ::= <statement> <next statement>

<next statement> ::= ';' <statement> <next statement> | NIL

<statement> ::= <Functional Operation>

<Functional Operation> ::= <FO_name> <FE_name> '(' <argument_list> ')' (see Functional Operation FRB Item)

where FO means Functional Operation and FE means Functional Entity.

<Boolean-expression> are Boolean expressions involving Boolean terms and arithmetic expressions connected by Boolean operators (AND, OR, NOT).

Comments are allowed in the statements provided that they are enclosed by '(*' and '*)'. Indentation is recommended.

1.4.3	Enterprise Activity Synchronisation

Enterprise Activities of a same Domain or of different Domains of an enterprise are allowed to communicate by exchanging messages and events for synchronisation. The language therefore allows the use of the following special functions defined as Functional Operations and which can be used as statements in the previous control structures:

1)	Generate Events: 'Generate' '(' <Event> ')'[',' <Object_View>] '

where <Event> is the name of the Event and <Object_View> is the name of the related Object View.

This function raises a CIMOSA Event, with an Object View possibly attached to it, which is sent to the outside via the Control Output of the Enterprise Activity using the function. (The Object View must have been instantiated).

2)	Send Synchronisation Messages : 'Send' '(' <EA-name> ',' <message> ')'

where <EA-name> is the name of the Enterprise Activity to which a synchronisation message <message> needs to be sent.

3)	Receive Synchronisation Messages: 'Receive' '(' <EA-name> ',' <message> ')'

where <EA-name> is the name of the enterprise Activity from which a synchronisation message <message> is expected.

4)	Acknowledge Receipt of a Message: 'Acknowledge' '(' <EA-name> ')'

indicates to activity <EA-name> that a message has been successfully received.

It can easily be seen that using these functions in the appropriate way, one can make:

-	two Enterprise Activities co-operate with one another

-	two Enterprise Activities be synchronised together (using a producer/consumer policy with acknowledgement)

-	two Enterprise Activities work in a asynchronous mode (no acknowledgement message)

1.4.4	Enterprise Activity Ending Status

Any Enterprise Activity has by definition a special variable attached to it and known by the supporting environment having to process the language. It is called Ending_Status. This variable is used in the Process Behaviour of the processes employing the Enterprise Activity.

Initialisation of this variable can be made in the Specified Enterprise Activity itself within one of the statements used in control structures of the language. (See example in 2.1). Thus this variable does not have to be declared in the Specified Enterprise Activity and can be used freely in the pseudo-code of the algorithm.

1.4.5	Final Remarks

The language makes use of pre-conditions. This is a way to implement some of the Declarative Rules defined at the Requirements Definition Modelling Level and which have to be taken into account during execution. Remember that in CIMOSA Release 1.0 no mechanism is provided by the Integrating Infrastructure to handle Declarative Rules.

2.	Background Section

2.1	Examples

Possible Activity Behaviour of a Specified Enterprise Activity processing valid customer orders:

ACTIVITY BEHAVIOUR:

{	DECLARE Customer_status: integer; Order: Order; 	Customer: Customer

PRE-CONDITIONS: 	Not-empty (Processable_Orders);

Not-empty (Customer_Info)

BEGIN (* Validate Customer *)

SD.Open (Processable_Orders);

FOREACH Order IN Processable_Orders DO

SD.Select (Customer_Info, Order, Customer);

PMG1.Check_Customer_Credit (Customer, 	Customer_status);

IF Customer_status = OK THEN (* Valid customer *)

PMG2.Create_New_Customer

(New_Customer_Info, Customer);

PMG3.Collect_All_Orders (Customer, Orders);

SD.Write (Orders);

ELSE (* Invalid customer *)

%.Display ("Customer status: ",Customer_status);

%.Write ("Invalid Customer: ", Customer);

END

Ending_Status := "Validation Completed"

END (* Validate Customer *);

POST-CONDITIONS: Dispose (Customer_status, Order, Customer)}

-	Functional Operations in this example are:

FO-01 'Open'

FO-02 'Select'

FO-03 'Write'

FO-04 'Check Customer Credit'

FO-05 'Create New Customer'

FO-06 'Collect All Orders'

FO-07 'Select'

-	SD, PGM1, PGM2 and PGM3 are Functional Entities representing data services and applications.

-	% represents reference by default to a Functional Entity in a Functional Operation. (See Functional Operation item).

-	Processable_Orders, Customer_Info, New_Customer_Info are Specified Object Views. All other variables are local parameters.

-	Pre-conditions make sure that the input files are not empty. The post-condition frees the local variables used.

2.2	Document References

1.	Ralston A. and Reilly E.D. (Eds.). Encyclopedia of Computer Science and Engineering, Van Nostrand Reinhold, New York, NY, 1983.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Functional Operation
CIMOSA Technical Baseline

Functional Operation

B12-2420. Version: 1.2; Last Update: 94.02.02

1.	Technical Section

1.1	Purpose and Scope

Defines the basic units of work to be executed by Functional Entities to realise the functionality of Specified Enterprise Activities.

1.2	Terms and Definitions

(1)	Functional Operation: is a basic unit of work in the Design Specification Model (or lowest level of granularity in the Function view). At run-time it is fully executed or not at all. It consists of a name, a reference to a Functional Entity in the Resource View and a list of arguments including a status code.

1.3	Abbreviations and Acronyms (none)

CIM:	Computer Integrated Manufacturing

IIS: 	Integrated Infrastructure

FO: 	Functional Operation

FE: 	Functional Entity

1.4	Description

1.4.1	Generalities

From the modelling point of view, a Functional Operation is a basic unit of work in CIMOSA. It is the atomic element of work, i.e., it is like a command which is fully executed or not at all. Functional Operations do not have any behaviour in the CIMOSA sense. No direct human intervention can be done on Functional Operations. The human intervention (start, stop, terminate, abort, restart) is provided only at the level of Business Process and Enterprise Activity, which may result indirectly in intervention on Functional Operations.

A Functional Operation is executed by a Functional Entity, which is a Resource able to perform completely on its own a (class of) Functional Operation(s) and to receive, send and store information. A Resource which is classified as a Functional Entity, must be able to communicate with the IIS via the relevant Presentation Services and to process the relevant external protocol. For more information about Functional Entities the reader is referred to the B32-series of items of the Resource View. Functional Operations are employed by the algorithm of the Activity Behaviour of Specified Enterprise Activities. Each Functional Entity can perform a limited set of Functional Operations as indicated in their Function Set. The structure of these callable functions fix the format (i.e. the list of arguments) of Functional Operations.

A Functional Operation can be executed with success or failure. After execution of the Functional Operation, an status code is returned to the Enterprise Activity via the list of arguments of the Functional Operation so that the Enterprise Activity is made aware of the Functional Operation execution status (success or failure). This status code has a CIMOSA pre-defined type (FO_Status) which is an integer (0 means correct execution, and other values correspond to given error codes defined by users). If the FE has no mean to fix the status code, the Presentation Services are supposed to do it so that the error code is always available from the point of view of the Enterprise Activity.

Remark: From the IIS point of view, a Functional Operation is a command issued to a Resource (Functional Entity). A Functional Operation can contain a non-empty-set of commands (i.e. it is like a macro) and each of these commands consists of one command statement and a set of parameters (arguments). The commands provided by the supplier of the Functional Entity should be used. In the case the supplier (i.e. vendor or implementor) of the Functional Entity only provides a set of primitives commands, it should be possible to create high level commands (macro) to prevent that the user has to "code" primitives in the model. The expansion of these high level commands is done by the Presentation Service of the IIS (described in the C5-series of items). However these are implementation issues not any further discussed in this item.

In the implemented system, (Implemented) Functional Operations (FOs) are either directly provided by Implemented Functional Entities (FEs), or are macros understood by Presentation Services, or become computer programs (i.e. software to be coded), or are implemented as database transactions.

1.4.2	Functional Operation Description

The Functional Operation is a construct that mediates between the user-oriented Function View as described in the Requirements Definition Model and the implementation-oriented Function View of the Implementation Description Model. A Functional Operation (FO) is a basic unit of work which can be used by a Specified Enterprise Activity and which can be performed by a Functional Entity. Therefore, a Specified Enterprise Activity is composed of a structured set of (Specified) Functional Operations connected to one another to form its Activity Behaviour in order to form a program of work.

Definition: Each Functional Operation is declared in the Function Set of the relevant Functional Entity and is called in Activity Behaviour using the dotted notation defined by a formal message structure as follows:

<Functional_Entity Name> "." <Functional_Operation Name> [(<list of arguments>)]

where:

-	<Functional_Operation Name> is the name of one of the callable functions of a Functional Entity

-	<Functional_Entity Name> is the name (or logical name) of the Functional Entity which can perform the Functional Operation. When the FE is an IIS Service, by default it becomes %, otherwise the IIS Service is explicitly mentioned (SD for System Data, RM for Resource Manager)

-	<list of arguments> is a sequence of names of typed input/output parameters separated by comma which pass the required information so that the operation can be performed. The sequence of arguments must comply with the formal declaration of the Functional Operation.

Note 1: The list of arguments can be empty.

Note 2: Some arguments are system parameters, i.e. they have predefined names and they are recognised by the IIS Services. In this case their name is prefixed by % (e.g. %Elapsed_Time). The final list of such system parameters remains open and will be defined by tool builders.

Note 3: The <Functional_Entity Name> can be a logical name to be instantiated at run-time among a list of alternatives. This allows a selection of a Resource among several as follows:

-	FE := RM.Select (FE1, FE2, FE3);

-	FE.FO-1 (p1, p2, OK);

FE is the logical name; FE1, FE2, FE3 are Functional Entities to select from and which can all perform FO-1.

1.4.3	Functional Operation Based Communication

Built-in CIMOSA Functional Operations exist. They include commands to send, receive and acknowledge messages among Specified Enterprise Activities. These are:

-	Send (activity, message, OK)

-	Receive (activity, message, OK)

-	Acknowledge (activity)

where message is the message name, activity is the activity identifier and OK is a parameter of type FO_Status.

The Functional Operation used to create Events in Activity Behaviour of a Specified Enterprise Activity is:

-	CreateEvent (event, object_view, OK)

where event is the Event identifier, object_view is the Object View identifier to be attached to the Event and OK is the status code. The effect of this Functional Operation is to create an occurrence of the Event and to send it in the Control Output of the occurrence of the Enterprise Activity calling it. Note, however, that before using this Functional Operation, the relevant Object View must be instantiated.

Other Functional Operations handled by Resource Management exist to lock and unlock Resources and channels.

-	Lock (resource)

-	Unlock (resource)

where resource is the identifier of the Resource to be locked or unlocked.

Important Remark: This modelling mechanism allows the communication between concurrent or co-operating Enterprise Activities and furthermore allows internal synchronisation of their processing. Therefore CIMOSA provides two synchronisation mechanisms for enterprise tasks which occur in the real-world: global synchronisation which will be under the IIS control because it is described in the logic of Procedural Rules of processes (e.g. activity 1 must start before activity 2), and operational synchronisation which is based on real-world events occurring at run-time (e.g. a part loading robot is shared by two work centres being involved in two separate manufacturing processes). This makes possible special situation such as "hand-shaking" for activities having to work co-operatively.

1.4.4	Level of Granularity

CIMOSA does not provide any rule to fix the level of granularity or atomicity of Functional Operations. This is decided by users according to the reality they try to model. A Functional Operation can be as small as "moving a part from position a to position b" to as large as "producing 100 parts of type "xx" as long as there is in the system a Functional Entity (i.e. a processor with a controller) which can understand the request and execute it.

2.	Background Section

2.1	Examples

Example 1: Functional Operation asking a robot to take a part from a pallet and to put it on a machine.

-	ROBOTx.move (part, pallet_pos, machine_pos, speed)

Example 2: Functional Operation asking a machine to run a program.

-	MACHINEy.Run (part_program_3)

Example 3: Functional Operation asking an application (i.e. a software package) to calculate a shop schedule.

-	APPLICATION2.schedule (production_plan, horizon, ...)

Other examples:

As examples of Data Storage Functional Operations we have:

-	Data Manipulation Functional Operations

FO-SD01 'Insert' (Data)

FO-SD02 'Select' (Data)

FO-SD02 'Delete' (Data)

FO-SD02 'Update' (Data)

- %.'Write' (Message)

- %.'Display' (Data)

Data is a list of variables declared in Activity Behaviour of Specified Enterprise Activity.

As examples of Application Functional Operations we can have:

-	Application Management Functional Operations (see callable services provided by the IIS)

for example:

-	Application.Prog [(argument_list)]

where Application is the name of the application (Functional Entity), Prog is the name of the program to be executed and the list of argument is optional (depending on the fact that the program does or does not require arguments).

As examples of Specified Human Functional Operations we can have an unlimited set of Functional Operations. They usually start by the verbs. Basic types can be:

-	Execution Functional Operations;

FO-EX01 'Do'

FO-EX02 'Perform'

-	Control Functional Operations;

FO-CR01 'Check'

FO-CR02 'Control'

FO- CR03 'Verify'

FO- CR04 'Measure'

FO- CR05 'Validate'

-	Management Functional Operations

FO-MG01 'Decide'

FO- MG02 'Report'

-	Clerical Functional Operations

-	Handling Functional Operations

-	Design Functional operations

-	etc.

As examples of Specified Machine Functional Operations we can have:

-	Machining Machine Functional Operations

FO-MA01 'Drill'

FO-MA02 'Turn'

FO-MA03 'Bore'

FO-MA04 'Tap'

FO-MA05 'Mill'

FO-MA06 'Press'

FO-MA07 'Debur'

FO-MA08 'Change Tool'

FO-MA09 etc.

-	Transportation Machine Functional Operations

FO-TR01 'Move'

FO-TR02 'Push'

FO-TR03 'Put'

FO-TR04 etc.

-	Robot Functional Operations

FO-RO01 'Rotate'

FO-RO02 'Move To'

FO-RO03 'Open Grip'

FO-RO04 'Close Grip'

FO-RO05 etc.

-	Measuring Machine Functional Operations

-	Part/Material Storage Functional Operations

-	Data Acquisition Functional Operations

FO-DA01 Get Sensor (data)

FO-DA02 Read (Bar-code)

- etc.

-	etc.

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Specified Event
CIMOSA Technical Baseline

Specified Event

B12-2500. Version: 1.2; Last Update: 94.07.12

1.	Technical Section

1.1	Purpose and Scope

Provides a specification for Events.

1.2	Terms and Definitions

(1)	Specified Event:

(a)	is a fact specifying a request to do something or a real-world happening occurring at a given instant in time from a given source and indicating a change in the state of the enterprise.

(b)	is a modelling construct inherited from the Requirements Definition Model. It can carry information (defined as an Specified Object View). It is used to trigger the execution of one or more Specified Domain Processes by initiating the processing of the associated Process Behaviour.

1.3	Abbreviations and Acronyms

DP:	Domain Process

EV:	Event

OC:	Organisation Cell

OU:	Organisation Unit

OV:	Object View

1.4	Description

This construct is used to describe Events at the Design Specification Modelling Level. It does not differ very much from the one used at the Requirements Definition Modelling Level, except by the facts

1	that if it comes from a resource, the Resource can be indicated at this modelling level

2	it is associated with time (timestamp) to indicate when it appeared

3	it has a priority which can be used to give priority in the case of several Events to be considered at the same time

Specified Events have a twin role in CIMOSA. Firstly, they initiate the processing of a Domain Process by creating an occurrence of it and triggering it. Secondly, they participate to the Specified Business Process and Specified Enterprise Activity synchronisation in Process Behaviour (without creating occurrences of these processes and activities). Each event can take both roles or only one of them at a given instant in time. A Specified Event specifies entities which can create occurrences of this Event instance and Process instances, occurrences of which can be triggered by these occurrences. The Event itself is a fact. It may have information associated to it. This is described in the form of a set of Specified Object Views defined on External Schemata in the Information View at the Design Specification Modelling Level. These External Schemata provide a specification of the Object Views identified for this Event instance.

Exogenous (external) Events are Events which are received from or sent to other Domains (CIMOSA or non-CIMOSA Domains). Thus they appear in one Domain and trigger Domain Processes in other Domains (in case of CIMOSA Domains). Endogenous (internal) Events are Events which are only used within one Domain.

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Specified Event instances of all types are described by the following template:

SPECIFIED EVENT (*)

Header
Type: Identifier: Name: Design Authority: Operation Responsibility: Operation Authority:	[relevant category - select from list <name>; inherited from RDM] [EV-<unique identifier>; RDM] [name of the Specified Event instance in the form: <adjective > <noun> <noun>: relates to the object causing the Event  <adjective>: qualifying attribute RDM] [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance. RDM] [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with responsibility for operation of this instance, new entry] [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with authority for operation of this instance, new entry] (**)
Body
A. Descriptional Properties:  DESCRIPTION OBJECT VIEW: TIMESTAMP: PRIORITY: B. Relational Properties: GENERATED BY: TRIGGERS	[textual description; optional] [<identifier> / <name> of Specified Object View instance defining information attached to occurrences of this Event instance, if any. RDM] [yy.mm.dd:hh.mm.ss:mmm (type defining date and time to be provided at occurrence creation time), new entry] Timestamp has a fixed value which is a type for date and time (and cannot be changed because it is known by the system). [an integer between 1 and 6 included, new entry] [non-empty list of <identifier> / <name> of Specified Domain or Specified Enterprise Activity instance, occurrences of which can generate an occurrence of this Event instance. RDM] [list of <identifier> / <name> of Specified Domain Process, (Specified Business Process, Specified Enterprise Activity or Resource) instances, occurrences of which can be triggered by occurrences of this Event instance. RDM]
2.	Background Section

2.1	Examples

SPECIFIED EVENT (*)

Header
Type: Identifier: Name: Design Authority: Operation Responsibility: Operation Authority:	Management order/Change request EV-04 'PCB Change Request' OU-01: 'M. Synders', OC-002 'Product Engineering' OC-002 'Product Engineering' OC-002 'Product Engineering'
Body
A. Descriptional Properties:  DESCRIPTION: RELATED OBJECT VIEW: TIMESTAMP: PRIORITY: B. Relational Properties: GENERATED BY: TRIGGERS:	Modification of specification at request of customer. This leads to a Change Request. OV-010 'PCB-data Date of Creation 6 (1: lowest priority; 6: highest priority). DP-04 'Prototypes Manufacturing' DP-05 'PCB Design'
2.2	Document References (none)

2.3	Open Issues (none)

(*)	Part of Header and Body inherited from RDM Level

(**)	Header and Body additional entries at DSM Level

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


DSM Level - Function View
 CIMOSA Outline

 Table of Contents

 Business Oriented Modelling

 DSM Level - Function View

 Function View, Design Specification Modelling Level

 Generic Building Blocks of the Function View, Design Specification Modelling Level

 Specified Domain

 Specified Domain Process

 Specified Business Process

 Process Behaviour

 Specified Enterprise Activity

 Activity Behaviour

 Functional Operation

 Specified Event

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Information View, Design Specification Modelling Level
CIMOSA Technical Baseline

Information View,

Design Specification Modelling Level

B22-1000. Version: 3.1; Last Update: 93.12.30

1.	Technical Section

1.1	Purpose and Scope

Provides the Information View constructs at the Design Specification Modelling Level and their relationships as perceived by the CIM information system designer.

1.2	Terms and Definitions

(1)	Information View, Design Specification Modelling Level:

(a)	is the Information View of the Design Specification Modelling Level as defined in the European Pre-norm (ENV 40 003).

(b)	consists-of:

non-empty-set-of Generic Building Blocks for design specification in the Information View and

set-of Building Block Types for design specification in the Information View and

set-of Partial Design Specification Models for the Information View and

one Particular Design Specification Model for the Information View.

1.3	Abbreviations and Acronyms

CEN:	Comitè Européen de Normalisation

CIM:	Computer Integrated Manufacturing

ENV:	European pre-Norm

ERA:	Entity-Relationship-Attribute approach

1.4	Description

The Information View of the Design Specification Modelling Level contains all the constructs to specify the Information System concerning business data and information of an enterprise. The CIMOSA Information View is described by Information View Modelling Paradigms.

The Design Specification Modelling Level of the Information View is made of three sub-parts:

1.	The Generic Design Specification Building Blocks which form a structured catalogue of all Generic Building Blocks and Building Block Types of the Information View used for design specification;

2.	The Partial Design Specification Models which make up a structured catalogue of classified, (partially) instantiated aggregations of Information View generic constructs used to instantiate Particular Design Specification Models;

3.	The Particular Design Specification Model which contains all Information System design specifications for the Information View of one individual enterprise.

In addition to Object View inherited from the Requirements Definition Modelling Level, there are four other Generic Building Blocks: Conceptual Schema, External Schema, Integrity Constraint and Database Transaction. They form the basis of an IT oriented "language" to be used to model static and dynamic properties of information at a detailed level, i.e. in a data-oriented way. At the Design Specification Modelling Level, the AMICE Project has selected the Entity-Relationship-Attribute (ERA) approach to support descriptions of External Schemata, Conceptual Schemata, Integrity Constraints and Database Transactions. The ERA methodology adopted is used to transform the object-oriented information model obtained at the Requirements Definition Modelling Level into an unambiguous, consistent, semantic data-oriented model at the Design Specification Modelling Level. CIMOSA, as an open architecture, can evolve to new information modelling paradigms when they become stable. For example, the ERA formalism used to specify Object Views, which presents today's state of the art in data modelling, is currently challenged by object-oriented data models.

2.	Background Section

2.1	Examples (none)

2.2	Document References

1.	ENV 40 003: Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling. CEN/CENELEC, 1990.

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Generic Building Blocks of the Information View, Design Specification Modelling Level
CIMOSA Technical Baseline

Generic Building Blocks of the Information View,

Design Specification Modelling Level

B22-2000. Version: 3.2; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Provides the list of Generic Building Blocks of the Information View to be used in the CIMOSA Reference Architecture and the Particular Architecture for the specification of a CIM Information System design.

1.2	Terms and Definitions

(1)	Generic Building Blocks of the Information View, Design Specification Modelling Level (ENV 12 204):

(a)	are used to build Partial Design Specification Models and Particular Design Specification Models.

(b)	set of Generic Building Blocks and Building Block Types of Business and IT oriented modelling constructs of the Information View. The set of Generic Building Blocks consists-of:

Business oriented Modelling

-	Specified Object View - OV

IT oriented Modelling

-	Conceptual Schema

-	External Schema

-	Integrity Constraint

-	Database Transaction

1.3	Abbreviations and Acronyms

CEN:	Comitè Européen de Normalisation

CIM:	Computer Integrated Manufacturing

ENV:	European pre-Norm

ERA:	Entity-Relationship-Attribute approach

1.4	Description

The CIMOSA Generic Building Blocks of the Information View at the Design Specification Modelling Level are used to build up the CIMOSA Information View Modelling Paradigm at this Modelling Level. These Generic Building Blocks allow the description of Partial and Particular Models of the Information View at the Design Specification Modelling Level in terms of Specified Object Views, External Schemata, Conceptual Schemata, Integrity Constraints and Database Transactions as well as constructs of the Entity-Relationship-Attribute (ERA) Methodology.

Specified Object View provides a specification of Object Views in terms of External Schemata.

Conceptual Schema is a representation of the entire information content of the enterprise Information System in a form that is somewhat abstract in comparison with the way in which data is physically stored.

External Schema (or external view) is a restriction defined on a Conceptual Schema for the need of some group of users or applications and for the specification of Object Views.

Integrity Constraint is a formal rule constraining the possible values of data defined in a Conceptual Schema.

Database Transaction is a set of data processing operations (or data manipulations) applicable to data defined in a Conceptual Schema.

Figure B22-2000/1 presents the Generic Building Blocks and their relations used in the Information View at the Design Specification Modelling Level.

Figure B22-2000/1: Generic Building Blocks and their Relations in the Information View at the Design Specification Modelling Level

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Specified Object View
CIMOSA Technical Baseline

Specified Object View

B22-2500. Version: 0.2; Last Update: 96.02.14

1.	Technical Section

1.1	Purpose and Scope

Describes the specification of an Object View.

1.2	Terms and Definitions

(1)	Specified Object View :

(a)	defines the generic description of an Specified Object View. Specified Object View Type is the basic construct used from which partial and particular Specified Object Views are instantiated. .

(b)	is a modelling construct inherited from the Requirements Definition Model, providing the description of one aspect of one or more Enterprise Objects. It therefore describes a subset of properties owned by one or more Enterprise Objects from a given stand-point. It is made of Information Elements and/or other Specified Object Views.

1.3	Abbreviations and Acronyms

RDM: 	Requirements Definition Model

EO:	Enterprise Object

OC:	Organisation Cell

OU:	Organisation Unit

OV:	Object View

1.4	Description

Specified Object View is a construct used to describe the specification of Object Views as defined at the Requirements Definition Modelling Level. It inherits most of the properties of an Object View as defined at the Requirements Definition Modelling Level but adds an entry to indicate External Schemata to be used in the specification of its Information Elements as defined in  terms of elements of the Conceptual Schema (entities, relationships and their attributes). Constraints expressed at the Requirements Definition Modelling Level are taken into account in the specification of External Schemata. This item specifies Object Views as information structures playing the role of global variables in the CIMOSA language (i.e. input and output variables for Enterprise Activities).

1.4.1	General Constraints

-	The instantiation of Specified Object Views at the Partial and Particular Design Specification Modelling Level is constrained by the defined Specified Object View Instantiation Rules (described in the D-series Items).

-	All Specified Object Views defined at the Design Specification Modelling Level will be specified in terms of Specified External Schemata.

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Specified Object View instances of all types are described by the following template:

SPECIFIED OBJECT VIEW (*)

Header
Type: Identifier: Name Design Authority: Operation Responsibility: Operation Authority:	[relevant category - select from list or inherited from RDM] [OV-unique number; RDM] [name of the Object View instance; RDM] [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance; RDM] [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with responsibility for operation of this instance; new entry (**)] [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with authority for operation of this instance; new entry]
Body
A. Descriptional Properties:  Description: Nature PROPERTIES: CONSTRAINTS: B. Relational Properties: LEADING OBJECT: RELATED OBJECTS: EXTERNAL SCHEMATA:	[short textual description; RDM] ['Physical' or 'Information'; RDM] [list of Properties of the Specified Object View instance; RDM] [list of constraints applicable to properties the Object View instance. The selection clause starts by the reserved word "WHERE" and is made of a conjunctive list of first-order predicates; optional; RDM] [<identifier> / <name> of the main Enterprise Object instance on which the Object View instance applies] list of <identifier> / <name> of other Enterprise Object instances related to the Object View instance] [non-empty list of <identifier> / <name> of External Schema instances defining the Object View instance; new entry]
2.	Background Section

2.1	Examples

OBJECT VIEW

Header
Type: Identifier: Name Design Authority: Operation Responsibility: Operation Authority:	Product Data OV-04 'Product Info' OU-05 'K. Maier', OC-006 'Sales' OC-006 'Sales' OC-006 'Sales'
Body
A. Descriptional Properties:  Description: Nature PROPERTIES: CONSTRAINTS: B. Relational Properties: LEADING OBJECT: RELATED OBJECTS: EXTERNAL SCHEMATA:	Product description from the sales department viewpoint Information Product_id:string[12] Product_Name:string[15] Description:string[30] Type_Code:string[5] Alternate_Code:string[5] ABC_Code:string[3] Leadtime:integer Standard_Cost:money Unit_of_Measure:integer Drawing_Id::string[12] Exist (Product_id); WHERE (Type_Code LIKE "ABC$") AND Leadtime <= 50 EO-02 'End Product' EO-03 'Product History' tbd
2.2	Document References (none)

2.3	Open Issues (none)

(*)	Part of Header and Body inherited from RDM Level

(**)	Header and Body additional entries at DSM Level

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


DSM Level - Information View
 CIMOSA Outline

 Table of Contents

 Business Oriented Modelling

 DSM Level - Information View

 Information View, Design Specification Modelling Level

 Generic Building Blocks of the Information View, Design Specification Modelling Level

 Specified Object View

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Resource View, Design Specification Modelling Level
CIMOSA Technical Baseline

Resource View,

Design Specification Modelling Level

B32-1000. Version: 0.6; Last Update: 93.12.31

1.	TECHNICAL SECTION

1.1	Purpose and Scope

Provides the constructs to describe enterprise resources at the Design Specification Modelling Level and their relationships as perceived by the CIM system designer.

1.2	Terms and Definitions

(1)	Resource View, Design Specification Modelling Level:

(a)	is the Resource View of the Design Specification Modelling Level as defined in the European pre-Norm (ENV 40 003).

(b)	consists-of

-	non-empty-set-of Generic Building Blocks for design specification in the Resource View and

-	set-of Building Block Types for design specification in the Resource View and

-	set-of Partial Design Specification Models for the Resource View and

-	one Particular Design Specification Model for the Resource View.

1.3	Abbreviations and Acronyms

CEN: 	Comité Européen de Normalisation

CIM:	Computer Integrated Manufacturing

ENV: 	European Pre-Norm

1.4	Description

At the Design Specification Modelling Level the alternative technical solutions (alternative resources) are provided to satisfy the capabilities at the Requirements Definition Modelling Level are described. From their evaluation the specifications of the technical choice are made. The CIMOSA Resource View is described by Resource View Modelling Paradigms. The Design Specification Modelling Level of the Resource View is made of three sub-parts:

1.	The Generic Design Specification Building Blocks which form a structured catalogue of all Generic Building Blocks and Building Block Types of the Resource View used for design specification;

2.	The Partial Design Specification Models which make up a structured catalogue of classified (partially) instantiated aggregations of Resource View generic constructs used to instantiate Particular Design Specification Models;

3.	The Particular Design Specification Model which contains all design specifications for the Resource View of one individual enterprise.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	ENV 40 003: Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling. CEN/CENELEC, 1990.

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Generic Building Blocks of the Resource View, Design Specification Modelling Level
CIMOSA Technical Baseline

Generic Building Blocks of the Resource View,

Design Specification Modelling Level

B32-2000 Version: 0.6; Last Update: 96.03.01

1.	TECHNICAL SECTION

1.1	Purpose and Scope

Provides the list of Generic Building Blocks used in the Resource View at the Design Specification Modelling Level.

1.2	Terms and Definitions

(1)	Generic Building Blocks of the Resource View, Design Specification Modelling Level (ENV 12 204):

(a)	are used to build Partial Design Specification Models and Particular Design Specification Models.

(b)	set of Generic Building Blocks and Building Block Types of the Resource View. The former consists-of:

-	Specified Capability Set - CS

-	Resource - RE

(c)	set of Generic Building Block components of the Resource View consists-of

-	Specified Capability Element

There is a dual use of the Specified Capability Set constructs for both required capability as defined for the Specified Enterprise Activity and provided capability as defined for the Specified Resource (see Specified Capability Set at the Design Specification Modelling Level).

1.3	Abbreviations and Acronyms

CEN:	Comité Européen de Normalisation

ENV:	European Pre-Norm

1.4	Description

CIMOSA Generic Building Blocks of the Resource View are used to build up CIMOSA Resource View Modelling Paradigms. A modelling paradigm is a structured, open set of primitive and high-level concepts, models, languages, methods and methodologies which are used to describe the static and dynamic properties of manufacturing enterprises. The Generic Building Blocks and their relations are shown in Fig. B32-2000/1 .

Fig. B32-2000/1: Generic Building Blocks and their Relations at the DSM level

The Resource View of the Design Specification Model logically describes the desired realisation of the Resource View at the Requirements Definition Modelling Level. It contains the specifications of the system to be implemented to realise the defined user requirements. As such it is the link between the requirements definitions and the implementation description. The Resource View at the Design Specification Modelling Level defines alternative solutions, i.e. a set of Alternative Resources which are derived from the Capability Sets required by Enterprise Activities. From this set of Alternative Resources a technical choice has to be made in the optimisation process, which results in a specified solution i.e. a set of specified Resources with its set of Specified Capabilities.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Specified Capability Set
CIMOSA Technical Baseline

Specified Capability Set

B32-2100 Version: 0.5; Last Update: 96.02.15

1.	Technical Section

1.1	Purpose and Scope

Defines Capability Sets provided by Resources at the Design Specification Modelling Level. Capabilities will be used by Resources to support the execution of Enterprise Activities.

1.2	Terms and Definitions

(1)	Specified Capability Set: dual use for both:

(a)	a modelling construct inherited from the Requirements Definition Model and defined as a collection of Capability Elements or Capabilities. It describes the set of Capabilities required by Specified Enterprise Activity(ies).

(b)	a modelling construct for characterising the functional, object related, performance and operational attributes of the Resource.

1.3	Abbreviations and Acronyms

CS:	Capability Set

EA:	Enterprise Activity

OC:	Organisation Cell

RE:	Resource

1.4	Description

The construct Capability Set describes the functional, object related, performance and operational attributes defined for an alternative Resource and specified for a specified Resource.

There are two statuses of the Capability Set construct at this level:

-	Defined Capability Set provided by an Alternative Resource, they are only defined to the extend necessary for simulation in order to make a technical choice.

-	Specified Capability Set which a Specified Resource should have. They must meet or exceed the Capabilities required by an Enterprise Activity, and to comply with certain design objectives and constraints. Specified Capability Set must be defined in such a detail that it is possible to make a product choice (i.e. select Implemented Resources).

Typification of Capability Sets is possible for Human, Machine and Application Capabilities.

Capability Set is used to describe :

-	Function Related Capabilities A Function Related Capability concerns the functionality of an Enterprise Activity and will be provided by a Resource. Examples are metal cutting or drilling of deep holes.

-	Object Related Capabilities An Object Related Capability applies to input objects of an Enterprise Activity or to that provided by a Resource like the range between minimum and maximum size or weight of a tool.

-	Performance Related Capabilities A Performance Related Capability is required by an Enterprise Activity or processed by a Resource. Examples are time performance, throughput or availability of a manufacturing cell.

-	Operation Related Capabilities An Operation Related Capability constrains operation related attributes required by an Enterprise Activity or provided by a Resource. Examples are skill of personnel or number of shifts per day.

Each Capability is an element, not a construct, with a name and a value range, e.g. max. elongation of 1.5 meter, tool diameter of 0.5 - 1.5 cm or spoken languages as English, French, German. The same Capability Set can be referred to by several Enterprise Activity instances but usually not by different Resource instances.

In the case of Human Capabilities, Operation Related Capabilities are also called competencies. They define human activities and qualifications to perform a given task such as cognitive abilities (to plan to decide, to solve problems, etc.). These human capabilities may be described in the form of competency trees (see Figure B32-2100/1).

Fig. B32-2100/1: Human Capabilities (Example of Competency Tree)

1.5	Description Template

SPECIFIED CAPABILITY SET (*) (Required/Provided Capability)

Header
Type: Identifier: Name: Design Authority: Operation Responsibility : Operation Authority :	[Relevant category - select from list (new entry (**)) or inherit from RDM] [CS-unique number; RDM/new entry] [name of this set of Capabilities; RDM/new entry] [<identifier>/<name> of the Specified Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance. RDM/new entry] [<identifier>/<name> of the Specified Organisation Unit and/or Organisation Cell responsible for this instance; new attribute (***) [<identifier>/<name>of the Specified Organisation Unit and/or Organisation Cell responsible for this instance; new attribute
Body
A. Descriptional Properties:  DESCRIPTION: CAPABILITIES :    Function Related:    Object Related:    Performance Related :    Operation Related: B. Relational Properties: WHERE USED:	[short textual description; optional RDM/new entry] [NIL or list of Capabilities Elements separated by semi-colon; RDM/new entry] [NIL or list of Capabilities Elements separated by semi-colon; RDM/new entry] [NIL or list of Capabilities Elements separated by semi-colon; RDM/new entry] [NIL or list of Capabilities Elements separated by semi-colon; RDM/new entry] list of [<identifier> / <name> of Resources which provide Capability Set and/or of Specified Enterprise Activities which require this instance of Capability Set; RDM]
There must be at least one Capability Element defined in a Capability Set. Each Capability Element is defined as: <name> ":" <range> <unit>, where: <range> defines the constrained values of the capability and <unit> indicates the unit of measure if required

<range> is either:

-	free text

-	a value (integer, real, string, Boolean)

-	a range of values defined either as:

- 	[a, b] means the value is between a and b where a and b are either both integers or both reals

- 	[-, b] means the value is less than b

- 	[a, -] means the value is greater than a

-	an enumeration of values separated by comma and enclosed by parentheses (e.g. (blue, green, yellow). 	All values in the enumeration must have the same data type.

<unit> is optional and can take usual abbreviation values of the international metric system (e.g. m, cm, N/m, Kg, etc.)

the international metric system (e.g. m, cm, N/m, Kg, etc.)

2. 	Background Section

2.1	Examples

SPECIFIED CAPABILITY SET (Required Capabilities)

Header
Type: Identifier: Name: Design Authority: Operation Responsibility : Operation Authority :	Move Class1 CS-02 'Moving Packed Products' OC-003 'Production Control' OC-008 'Shipping' OC-009 'Plant Services'
Body
A. Descriptional Properties:  DESCRIPTION: CAPABILITIES :    Function Related:    Object Related:    Performance Related :    Operation Related: B. Relational Properties: Where Used:	3-shift operation transportation of mechanical products packed in wooden boxes 3-dimensional movement inside building 12: (200x150x4 m3);  acceleration: < 0,1g; vibration tolerances: < 3Hz; Size: up to 1x1x1m3; Weight: up to 500 Kg Average number of boxes to be moved: up to 50/h Operation: 3 shifts (main capacity required 8:00h to 17:00h) EA-03 'Move Packed Products'
SPECIFIED CAPABILITY SET (Provided Capability)

Header
Type: Identifier: Name: Design Authority: Operation Responsibility : Operation Authority :	Move Class1 CS-03 Overhead Crane OC-010 'Production Planning' OC-008 'Shipping' OC-009 'Plant Services'
Body
A. Descriptional Properties:  DESCRIPTION: CAPABILITIES :    Function Related:    Object Related:    Performance Related :    Operation Related: B. Relational Properties: Where Used:	Transportation of payloads in 3-shift operation  3-dimensional movement inside building 12: (200x150x4 m3);  Payload: (Size: up to 1,5x1,5x1m3, Weight up to 1.000 Kg);  acceleration tolerances: < 0,1g; vibration: < 1Hz; Platform Carrier (3-sides accessible) with automatic Load/Unload capability Start/Stops: (up to 150/h); Movement: (up to ,5m/sec), Load/Unload: (30 sec) Operation: 3 shifts (main capacity required 8:00h to 17:00h) RE-01 'Overhead Crane'
Comment: The Required Capability defined by the Capability Set CS-03 can be satisfied by the resource RE-01 (Functional Entity FE-01) 'Overhead Crane' which provides the Performance Capability: 'the average number of boxes that can be moved per hour is 40 to 50'.

2.2	Document References (none)

2.3	Open Issues (none)

(*)	Part of Header and Body inherited from RDM Level

(**)	Header and Body additional entries at DSM Level for Provided Capability Set

(***)	Header and Body additional attributes at DSM Level for all Capability Sets

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Resource
CIMOSA Technical Baseline

Resource

B32-2200. Version: 0.5; Last Update: 9602.15

1.	TECHNICAL SECTION

1.1	Purpose and Scope

Defines the construct Resource at the Design Specification Modelling Level.

1.2	Terms and Definitions

(1)	Resource (represents an Enterprise means which):

(a)	has a Specified Capability Set characterising the functional, object related, performance and operational attributes of the Resource.

(b)	is distinguished between active resource objects (Functional Entity in the Resource View) and passive resource objects (Resource Component)

(c)	is used as a Resource Input of some Specified Enterprise Activity and is subject to a resource scheduling activity.

1.3	Abbreviations and Acronyms

IIS:	Integrating Infrastructure

CS:	Capability Set

FE:	Functional Entity

AID:	AMICE Implementation Description Language

OC:	Organisation Cell

RE:	Resource

1.4	Description

The Generic Building Block Resource must fulfil the following derived requirements :

1.	modelling of Resources at various levels of abstraction using decomposition and aggregation.

2.	model precisely the implemented resources with their static and dynamic properties.

3.	provide differentiation on nature of Resources (e.g., Human, manufacturing machine, computer) as well as their structure (physical, logical, static and dynamic) .

4.	modelling of physical, electronic or logical addresses of resources

5.	satisfy requirements of the IIS Resource Management Service.

6.	one common Generic Building Block to model alternative, specified or implemented Resources.

7.	one common Generic Building Block to model the different characteristics of Resources

There are two different statuses of the Resource construct at this level:

-	Alternative Resources which are derived from the Capability Sets required to perform an Enterprise Activity, which defines Defined Capability Sets to satisfy the Capabilities required. Alternative Resources are only defined to the extend necessary to make a technical choice

-	Specified Resources which are obtained from the Alternative Resources by making a technical choice (in the optimisation process), which provide specified Capability Sets which must meet or exceed the Capabilities required by an Enterprise Activity. Specified Resources are defined in such a detail that it is possible to make a product choice.

The Resource construct applies to Functional Entities, Resource Sets, Resource Cells and Components. Apparently all these are in fact views of some Enterprise Objects in CIMOSA terms (or Object Views) which play the role of a Resource at certain times of their life cycles. Therefore, they do not need to be redefined as such in the Resource View. The Resource View should only provide resource management information and the list of Functional Operations for Functional Entities, i.e. active entities used in support of to the execution of Enterprise Activities.

The list of Functional Operations of a Resource is given by the entry "Command Set" of the construct. Resources which are Functional Entities have a set of Callable Functions with which the Front End Services can activate a Functional Entity (Resource). Functional Entities are directly connected to the Integrating Infrastructure (IIS).

1.5	Description Template:

RESOURCE (*)

Header
Type: Identifier: Name: Design Authority: Operation Responsibility : Operation Authority:	[relevant category - select from list] [RE-<unique number>] [<name> of the Resource instance] [<identifier> / <name> of Specified Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance] [<identifier>/<name> of the Specified Organisation Unit and/or Organisation Cell with responsibility for operation of this instance] [<identifier>/<name> of the Specified Organisation Unit and/or Organisation Cell with authority for operation of this instance]
Body
A. Descriptional Properties:  DESCRIPTION: CAPABILITY SET : CLASS : OPERATION SET: OBJECT VIEW : B. Relational Properties: PART OF: CONSISTS OF:	[short textual description] [<identifier> / <name> of the Capability Set defining the provided capabilities of this Resource instance]  [value is either "Functional Entity" or "Resource Cell" or "Resource Set" or "Resource Component"] [list of all Functional Operations executable by this Resource instance. Each Functional Operation is defined by its name FO-name and its input and output arguments as follows:     <FO-name> "(" "IN" <parameter-list> "," "OUT" <parameter-list> ","     "INOUT" <parameter-list> ")". Does not apply to Resource Components]  [<identifier> / <name> of the Object View instance defining neccessary descriptive characteristics (e.g. capacity, availability, location, cost drivers, etc.) of this Resource instance]  [NIL or list of <identifier> / <name> of Functional Entity instances of which this Resource is a component]  [NIL or list of <identifier> / <name> of Resource instances which are part of this Resource]
Remarks: The Operation Set entry provides the list of Functional Operations of the Resource, except if its class is "Resource Component" (in this case, it is left empty). The Consists Of entry can refer to any class of Resources. The Part Of entry can only refer to Functional Entities, Resource Cells or Resource Sets.

2.	Background Section

2.1	Example

RESOURCE at the Design Specification Modelling Level : Overhead Crane

Header
Type: Identifier: Name: Design Authority: Operation Responsibility : Operation Authority:	Resource - Moving Class1 RE-01 'Overhead Crane' OC-11 'Plant Engineering' OC-008 'Shipping' OC-009 'Plant Services'
Body
A. Descriptional Properties:  DESCRIPTION: CAPABILITY SET : CLASS : OPERATION SET: OBJECT VIEW : B. Relational Properties: PART OF : CONSISTS OF :	Overhead Crane to move Packed Products in Building 12 CS-02 'Moving Packed Products' FE Functional Entity Load ("IN" Position, Weight, Secure Load, "OUT" Ready to move) Move ("IN" Start Position, End Position, "OUT" Movement completed) Unload ("IN" Position, Weight, Release Load, "OUT" Ready to move) OV-051 'Overhead Crane' (Physical) FE-02 'Plant Facility Tool' Not applicable
Comments:

In order to perform the Enterprise Activity EA-03 'Move Packed Product', two alternative Resource types are defined :RE-01 'Overhead Crane' which has one Alternative Resource occurrence and RE-02 'Automatic Guided Vehicle' which has two Alternative Resource occurrences.

2.2	Document References (none)

2.3	Open Issues (none)

(*)	New  construct at DSM Level

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Resource Component
CIMOSA Technical Baseline

Resource Component

B32-2210. Version: 1.2; Last Update: 96.02.15

1.	TECHNICAL SECTION

1.1	Purpose and Scope

Presents a formal definition and description of the term Resource Component, one of the appearance forms of a passive Resource, as it is used in the CIMOSA Resource View.

1.2	Terms and Definitions

(1)	Resource Component: is a passive Resource. It is a physical object that provides a specified functionality, but cannot perform Functional Operations on its own, its command set is empty. A Resource Component cannot be decomposed any further.

1.3	Abbreviations and Acronyms

CS:	Capability Set

OC:	Organisation Cell

RE:	Resource

1.4	Description

To identify those Resources in the models which are components of a Functional Entity. These components are incapable of executing Functional Operations on their own. In the Resource View Modelling Paradigm a number of constructs are identified, one of which is the Resource construct. A Resource can appear as a Resource Component. A Resource Component is required by a Functional Entity to perform (or help to perform) a Functional Operation. The Resource Component cannot perform the Functional Operation on its own, its command set is empty. A Resource Component can also be part of a Resource Set or Resource Cell.

Resource Components are aggregated:

-	permanently into Resources, thereby becoming part of the Resource (e.g. control device in an NC-machine);

-	temporarily into physical Resource Sets during Enterprise Operations in order to execute the occurrence of an Enterprise Activity. After the execution of the Enterprise Activity, the Resource (Set) is partially dismantled and the Resource Component is independent again (e.g. a cutting tool or fixture).

1.5	Template (Resource)

2.	Background Section

2.1	Examples

RESOURCE Component at the Design Specification Modelling Level : Control Device

Header
Type: Identifier: Name: Design Authority: Operation Responsibility : Operation Authority:	Resource Component - Electronic RE-02 'Control Device' OC-009 'Plant Engineering' OC-007 'Profit Center s/v' OC-007 'Profit Center s/v'
Body
A. Descriptional Properties:  DESCRIPTION: CAPABILITY SET : CLASS : OPERATION SET: OBJECT VIEW : B. Relational Properties: PART OF : CONSISTS OF :	Tape Drive Control Device to operate Milling Machine Class 1 NIL Resource Component NIL OV-052 'Tape Drive Control Device' (Physical) RE-03 'CNC Milling Machine' NIL
2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Functional Entity in the Resource View
CIMOSA Technical Baseline

Functional Entity in the Resource View

B32-2220. Version: 1.2; Last Update: 96.02.15

1.	TECHNICAL SECTION

1.1	Purpose and Scope

Describes how the class of active Resources is used in the Resource View.

1.2	Terms and Definitions

(1)	Functional Entity: is an active Resource able to perform, completely on its own, a (class of) Functional Operation(s). A Resource which is classified as a Functional Entity, must be able to communicate with the IIS and to process the relevant external protocol (Human Front-End External Protocol, Machine Front-End External Protocol, Application Front-End External Protocol) of its Presentation Services.

1.3	Abbreviations and Acronyms :

IIS:	Integrating infrastructure

CS:	Capability Set

OC:	Organisation Cell

OV:	Object View

RE:	Resource

1.4	Description

1.4.1	Purpose and Objectives

To identify those Resources in the models which are Functional Entities i.e. active components of the enterprise. Functional Entities are capable of executing Functional Operations on their own. The Objective is to model those Resources capable of communicating with an instance of the Presentation Services of the IIS.

1.4.2	Derived Requirements

1.	To identify the relevant instance of the IIS Presentation Service responsible for the Functional Entity in the model.

2.	To model the command sets of the Functional Entities.

3.	The common Generic Building Block Resource should be used for this purpose.

1.4.3	Introduction

A Functional Entity is a Resource able to support a (class of) Functional Operation(s). Functional Entities are directly linked to the IIS Presentation Service and require Resource Components. (See B32-2210). A Functional Entity contains:

-	a device to provide the functionality;

-	a control unit to communicate with the IIS and the protocol;

-	a protocol-converter if the control unit cannot process the protocol directly.

Three types of Functional Entities are defined to perform Functional Operations:

-	Human Functional Entities,

-	Machine Functional Entities,

-	Application Functional Entities.

Functional Entities which do not directly support Enterprise Activities are:

- 	Data Storage Functional Entities: used to store information. These Functional Entities must be able to communicate with the IIS and to process the External Protocol of the Information Services.

- 	Communication Functional Entities: must be able to process the External Protocol of the Common Services.

1.5	Template (Resource)

2.	Background Section

2.1	Examples

Functional Entity at the Design Specification Modelling Level : Milling Machine

Header
Type: Identifier: Name: Design Authority: Operation Responsibility : Operation Authority:	Resource -Functional Entity FE-03 'CNC Milling Machine' OC-009 'Plant Engineering' OC-007 'Profit Center s/v' OC-007 'Profit Center s/v'
Body
A. Descriptional Properties:  DESCRIPTION: CAPABILITY SET : CLASS : OPERATION SET: OBJECT VIEW: B. Relational Properties: PART OF : CONSISTS OF :	CNC Milling Machine Class 1; for Metal cutting CS-04 'Milling Machine' Functional Entity Start Program ("IN" Install Fixture, Load Part, "OUT" Start Program  completed) Operation ("IN" Machining, Handle Exception, "OUT" Operation completed) OV-050 'Milling Machine' (Physical) RE-06 'Machining Center' RE-05 'Cutting Unit', RE-02 'Control Device', RE-04 'Fixture'
2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Resource Set
CIMOSA Technical Baseline

Resource Set

B32-2230 Version: 1.2; Last Update: 96.02.15

1.	Technical Section

1.1	Purpose and Scope

Describes the concept of Resource Set.

1.2	Terms and Definitions

(1)	Resource Set:

(a)	behaves as a Resource;

(b)	fully supports a (class of) Specified Enterprise Activity(ies) as Resource Input;

(c)	is a temporary physical aggregation of Functional Entities and/or Resource Components in the Enterprise Operation Environment; considered as a whole (Functional Entity in the Resource View)

(d)	is a permanent logical aggregation of Functional Entities and/or Resource Components if defined in the Enterprise Engineering Environment.

1.3	Abbreviations and Acronyms

IIS:	Integrating Infrastructure

CS:	Capability Set

OC:	Organisation Cell

OV:	Object View

RE:	Resource

1.4	Description

1.4.1	Purpose and Objectives

To model the set of Resources which are to be dynamically acquired and relinquished. The Objective is to allow the dynamic assembly of sets of Resources required to execute an instance of a Functional Operation. i.e., the Functional Entity and all necessary components (e.g., tools).

1.4.2	Derived Requirements

1.	To provide a model (Resource Set) of the Functional Entity and all components (e.g., Tools) required to execute an instance of a Functional Operation.

2.	The common Generic Building Block Resource should be used for this purpose.

1.4.3	Introduction

In the Resource View Modelling Paradigm a number of constructs are identified, one of which is the Resource construct. A Resource can appear as a Resource Set. A Resource Set actually is the Resource Input of a (class of) Enterprise Activity(ies). It describes a physical or logical aggregation of Functional Entities and Resource Components.

Physical Resource Set

Fig B32-2230/1 : Physical Resource Set

A group of Functional Entities and/or Components temporarily aggregated, but considered as whole, in the Enterprise Operation Environment to execute a (number of) Enterprise Activity occurrence(s) is called a Physical Resource Set  (Figure B32-2230/1). This includes the 'set-up' and 'tear-down' of the Physical Cells with tools and operators required for a specific occurrence of an Enterprise Activity. It is a dynamic physical implementation of Resources at a certain location during a certain time period based on the Resource availability and scheduling constraints prevailing at that time. Thus, a Physical Resource Set exists only in the Enterprise Operation Environment (run time). An example of a physical Resource Set is a (manufacturing) workstation.

Logical Resource Set

Figure B32-2230/2. : Logical Resource Set

If the Enterprise Activity parameters are provided in the Enterprise Operation Environment, the actual Capabilities required are only determined at this point in time. However, in the Enterprise Engineering Environment, a set of Resources has been specified  for the established range of Capabilities (all possible parameters) of a defined class of Enterprise Activities. This permanent Logical Resource Set (Figure B32-2230/2) can be parameterised such that it allows run-time selection of Resources out of this set. Thus at run-time, it is converted into a Physical Resource Set. An Alternative Resource Set defines one alternative aggregation of Resource types to alternatively support an Enterprise Activity.

NB.	If a Resource Set is determined during Engineering Design for single purpose machines (sets), then the Resource Input is a Resource. This means that this (these) Resource(s) are (permanently) linked to one Enterprise Activity.

1.5	Template (Resource)

2.	Background Section

2.1	Examples

2.1.1	Physical Resource Set

Parameters of Enterprise Activity occurrence, related to part QQ-pn005 determines the following requirements:

1 Press of 100 tons EP-100 and

1 Rotor Stamping Tool no ST-RO-005 and

1 Robot Cell, Type RCE-015 and

2 Part Feeder, Type PF-SC and PF-WA

1 Operator OP-R5.

Available Pool of Resources (not for Press and Stamping Tool)

Resource	Robot Cell RCE-015	Part Feeder PF-SC	Part Feeder PF-WA	Operator
Resource (unit)	RCE-015/001	PF-SC/001	PF-WA/008	OP-R5/11023
	RCE-015/002	PF-SC/005	PF-WA/009	OP-R5/13133
			PF-WA/013	OP-R5/23498
PHYSICAL RESOURCE SET: Rotor Stamping Set

Header
Type: Identifier: Name: Design Authority: Operation Responsibility: Operation Authority:	Resource Set - Physical RE-07 'Rotor Stamping Set' OC-009 'Plant Engineering' OC-007 'Profit Center s/v' OC-007 'Profit Center s/v'
Body
A. Descriptional Properties:  DESCRIPTION: CAPABILITY SET : CLASS : OPERATION SET : OBJECT VIEW : B. Relational Properties: PART OF : CONSISTS OF :	temporary set of resources for stamping rotor parts (QQ-pn005) CS-05 'Parts Stamping' Functional Entity Set-up Set ("IN" Set-up Resources, "OUT" Set-up completed) Start Program ("IN" Load Part, "OUT" Start Program completed) Operation ("IN" Machining, Handle Exception, "OUT" Operation  completed) Tear-down Set ("IN" Remove Connections, "OUT" Tear-down completed) OV-053 'Stamping Set' (Physical) RE-06 'Machining Center' RE-08/1 'Press' (100 tons), RE-09/1 'Stamping Tool' (no ST-RO-005), RE-10/1 'Part Handling Device' (Type RCE-015, Type PF-SC, Type PF-WA), RE-11/1 'Operator' (Type OP-P)
2.1.2	Logical Resource Set

Defined set for ENTERPRISE ACTIVITY TYPE: MAKE Stamping

In order to make a stamping - independent of the part number - the following resource types are required:

1. 	PRESS (depends to some extent on the part no., but can be used for several different parts)

2. 	STAMPING TOOL (unique to the part no. cannot be used for other parts)

3. 	PART HANDLING DEVICE (load/unload depends less on part no. than part feeding does)

4. 	OPERATOR (does not depend on the part no.)

LOGICAL RESOURCE SET: MAKE Stamping Set

Header
Type: Identifier: Name: Design Authority: Operation Responsibility : Operation Authority:	Resource Set - Logical RE-12 'Stamping Set' OC-009 'Plant Engineering' not applicable not applicable
Body
A. Descriptional Properties:  DESCRIPTION: CAPABILITY SET : CLASS : CLASS : OPERATION SET: OBJECT VIEW : B. Relational Properties: PART OF : CONSISTS OF :	temporary set of resources for stamping parts  CS-05 'Parts Stamping' Physical Resource Set Functional Entity Set-up Set ("IN" Set-up Resources, "OUT" Set-up completed) Start Program ("IN" Load Part, "OUT" Start Program completed) Operation ("IN" Machining, Handle Exception, "OUT" Operation  completed) Tear-down Set ("IN" Remove Connections, "OUT" Tear-down completed) OV-053 'Stamping Set' (Physical) RE-06 'Machining Center' RE-08'Press', RE-09 'Stamping Tool', RE-10 'Part Handling Device',  RE-11 'Operator'
2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Resource Cell
CIMOSA Technical Baseline

Resource Cell

B32-2240. Version: 1.2; Last Update: 96.02.15

1.	Technical Section

1.1	Purpose and Scope

Describes the concept of Resource Cell.

1.2	Terms and Definitions

(1)	Resource Cell:

(a)	behaves as a Resource;

(b)	is a permanent aggregation of Functional Entities and/or Resource Components; considered as a whole (Functional Entity in the Resource View),

(c)	can be a physical aggregation, describing the physical arrangement of Resources in the Enterprise;

(d)	can be a logical aggregation, based on classes of Resources or Enterprise Activities they support.

1.3	Abbreviations and Acronyms

IIS:	Integrating Infrastructure

CS:	Capability Set

OC:	Organisation Cell

OV:	Object View

RE:	Resource

1.4	Description

1.4.1	Purpose and Objectives

To allow the logical and physical aggregation of Resources. The objective is to model all logical and physical structures of the enterprise resources.

1.4.2	Derived Requirements

1.	Modelling of aggregation and decomposition of Resources.

2.	Top-down and bottom-up traceability.

3.	Can exist on the level of a Resource

4.	The common Generic Building Block Resource should be used for this purpose.

1.4.3	Introduction

In the Resource View Modelling Paradigm a number of constructs are identified, one of which is the Resource construct. A Resource can appear as a Resource Cell, a permanent aggregation of Functional Entities and Resource Components. The aggregation may be based on:

- 	the Functions they support:

-	a Job-oriented Cell. This supports a class of Enterprise Activities.

-	a Flow-oriented Cell. This supports (the Enterprise Activities of) a Business Process or even a class of Business Processes.

-	collections of Resources because they have a certain degree of commonality.

Figure B32-2240/1. : Physical Resource Cell

The hierarchical concept of aggregating Resources is also applicable to Resource Cells. This means that a Cell may be part of a larger Resource Cell, and/or may contain a number of subclass. Similar Business Processes, for instance, may be supported by different cell subclasses each consisting of Functional Entities that are part of one joint Flow-oriented Resource Cell. Resource Cells can even be aggregated into areas up to plant level. The way the Resources in a Cell are coupled determines the Cell behaviour when one of the Resources fails. The Resources in a Cell can be uncoupled, loosely coupled, tightly coupled, or the Cell can even behave as one Functional Entity.

A Resource Cell can exist physically or logically:

-	A Physical Resource Cell (Figure B32-2240/1) represents the physical aggregation of the Resources in the Enterprise, i.e. how the Resources have been 'physically implemented' (the arrangement on the shop-floor). It describes the actual (layout of) Functional Entities and Resource Components,, volumes, etc.).

Figure B32-2240/2. : Logical Cell

-	A Logical Resource Cell  (Figure B32-2240/2) is a virtual aggregation of Resources. It is based on classes of Enterprise Activities (or Business Processes) which it can support. It also could be based on Resources (Types, Properties). A Logical Cell does not exist physically.

-	An Alternative Logical Cell represents an aggregation of Resources Types capable to alternatively support a group of Enterprise Activities and may be used to reflect both a job-oriented structure or a task-oriented one.

1.5	Template (Resource)

2.	Background Section

2.1	Examples

2.1.1	 Physical Cell

Available Pool of resources :

Resource	Milling Machine  AB	Robot RO- XY	Robot Controller  RC-YZ	Transport Element  TE-AB
Resource (unit)	AB 4711/001	RO-XY/001	RC-YZ/011	TE-AB/083
	AB-4711/002		RC-YZ/012	TE-AB/084
				TE-AB/088
				TE-AB/133
1. 	A Physical Cell (Milling Cell MCE-015) is a RESOURCE Cell consisting of: the following Resources:

-	2 Milling Machine AB (Resource

-	1 Robot RO-XY (Resource)

-	1 Robot Controller Unit RC-YZ (Resource)

-	2 Transport Elements TE-AB (Resource)

2. 	An occurrence of Physical Cell (Milling Cell MCE-015/01) is a RESOURCE Cell consisting of: the following Resources:

-	2 Milling Machine AB (Resource 	AB 4711/001 and AB 4711/002

-	1 Robot (Resource): 	RO-XY/001

-	1 Robot Control Unit (Resource): 	RC-YZ/012

-	2 Transport Elements (Resource): 	TE-AB/088 and TE-AB/133

PHYSICAL RESOURCE SET: Milling Cell

Header
Type: Identifier: Name: Design Authority: Operation Responsibility : Operation Authority:	Resource Cell (Physical) RE-13 'Milling Center' OC-009 'Plant Engineering' OC-007 'Profit Center s/v' OC-007 'Profit Center s/v'
Body
A. Descriptional Properties:  DESCRIPTION: CAPABILITY SET : CLASS : OPERATION SET : OBJECT VIEW : B. Relational Properties: PART OF :  CONSISTS OF :	Set of milling workstations for milling metal shafts CS-06 'Milling Cell' Functional Entity Start Program ("IN" Load Part, "OUT" Start Program completed) Operation ("IN" Machining, Handle Exception, "OUT" Operation completed)- OV-054 'Milling Cell' (Physical) RE-06 'Machining Center' RE-03/1 'CNC Milling Machine' (AB 4711/001&002), RE-14/1 'Robot' (RO-XY/001), RE-15/1 'Control Unit', RE-16/2 'Part Feeder' (Type PF-SC; Type PF-WA), RE-11/1 'Operator' (Type OP-P)
2.1.2	Logical Cells:

1.	Aggregation of Function (Enterprise Activities = job-oriented)

-	all resources supporting the Enterprise Activities : Cut Metal

2.	Aggregation of Function (Business Processes = flow-oriented)

-	all resources supporting the Business Process : Make Gear Box

3.	Aggregation of Resources (Types)

-	all resources, Type = ROBOT

4.	Aggregation of Resources (Properties)

-	all resources with Property = Electrical.

LOGICAL RESOURCE CELL: Cut Metal

Header
Type:  Identifier: Name: Design Authority: Operation Responsibility : Operation Authority:	Resource Cell (logical) RE-17 'Milling Cell' OC-009 'Plant Engineering' not applicable not applicable
Body
A. Descriptional Properties:  DESCRIPTION: CAPABILITY SET : CLASS : OPERATION SET : OBJECT VIEW : B. Relational Properties: PART OF : CONSISTS OF :	Workshop for Milling Operations CS-07 'Milling Cell' Logical Resource Cell Start Program ("IN" Load Part, "OUT" Start Program completed) Operation ("IN" Machining, Handle Exception, "OUT" Operation completed)- OV-054 'Milling Cell' (Physical) RE-06 'Machining Center' RE-03 'CNC Milling Machine'
2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


 CIMOSA Outline

 Table of Contents

 Business Oriented Modelling

 DSM Level - Resource View

 Resource View, Design Specification Modelling Level

 Generic Building Blocks of the Resource View, Design Specification Modelling Level

 Specified Capability Set

 Resource

 Resource Component

 Functional Entity in the Resource View

 Resource Set

 Resource Cell

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


DSM Level - Organisation View
 CIMOSA Outline

 Table of Contents

 Business Oriented Modelling

 DSM Level - Organisation View

 Organisation View, Design Specification Modelling Level

 Generic Building Blocks of the Organisation View, Design Specification Modelling Level

 Specified Organisation Cell

 Specified Organisation Unit

 Specified Organisation Element

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Organisation View, Design Specification Modelling Level
CIMOSA Technical Baseline

Organisation View,

Design Specification Modelling Level

B42-1000. Version: 2.1; Last Update: 94.02.15

1.	Technical Section

1.1	Purpose and Scope

Provide the Organisation View Building Blocks at the Design Specification Modelling Level and their relationships as perceived by the CIM system designer.

1.2	Terms and Definitions

(1)	Organisation View, Design Specification Modelling Level:

(a)	is the Organisation View of the Design Specification Modelling Level as defined in the European pre-Norm (ENV 40 003).

(b)	consists-of

-	non-empty-set-of Generic Building Blocks and Building Block Types for design specification in the Organisation View

-	set-of Partial Design Specification Models for the Organisation View and

-	one Particular Design Specification Model for the Organisation View.

1.3	Abbreviations and Acronyms (none)

1.4	Description

At the Design Specification Modelling Level the Organisation View describes possible solutions to organisational structures to satisfy the over all objectives of the enterprise. The specifications of the possible solutions are not defined in terms of time, place and amount.

The CIMOSA Organisation View is described by Organisation View Modelling Paradigms. The Design Specification Modelling Level of the Organisation View is made up of three sub-parts:

1.	The Generic Design Specification Building Blocks which form a structured catalogue of all Generic Blocks (or basic construct types) of the Organisation View  used for design specification;

2.	The Partial Design Specification Models which make up a structured catalogue of partially instantiated versions of Organisation View  generic constructs for design specification, used to instantiate Particular Models;

3.	The Particular Design Specification Models which contains all design specifications for the Organisation View  of one individual enterprise.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC, 1990: Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling.. ENV 40 003

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Generic Building Blocks of the Organisation View, Design Specification Modelling Level
CIMOSA Technical Baseline

Generic Building Blocks of the Organisation View,

Design Specification Modelling Level

B42-2000. Version: 1.3; Last Update: 96.02.15

1.	Technical Section

1.1	Purpose and Scope

Provide the list of the Generic Building Blocks used in the Organisation View at the Design Specification Modelling Level.

1.2	Terms and Definitions

(1)	Generic Building Blocks of the Organisation View, Design Specification Modelling Level (ENV 12 204):

(a)	are the basic building blocks used to build Partial Design Specification Models and Particular Design Specification Models.

(b)	set of Generic Building Blocks and Building Block Types of the Organisation View. The former consists-of:

-	Specified Organisation Cells - OC

-	Specified Organisation Units - OU

(c)	set of Generic Building Block components of the Organisation View consists-of:

-	Specified Organisation Elements

1.3	Abbreviations and Acronyms (none)

1.4	Description

Figure B42-2000/1: Generic Building Blocks of the Organisation View Modelling Paradigm

CIMOSA Generic Building Blocks of the Organisation View are used to build up CIMOSA Organisation View Modelling Paradigms. A Modelling Paradigm is a structured, open set of primitive and high-level concepts, models, languages, methods and methodologies that are used to describe the static and dynamic properties of the Decision System of manufacturing enterprises.

In the Organisation View of the Design Speci-fication Modelling Level CIMOSA describes in a formal way the structure and relations necessary in an enterprise to fulfil its objectives, in terms of Organisation Cells, Organisation Units, Organisation Elements and Organisation Rela-tionships (see Figure B42-2000/1). This Figure also indicates the relations of the Organisation View to other modelling views.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Specified Organisation Cell
CIMOSA Technical Baseline

Specified Organisation Cell

B42-2100. Version: 2.2; Last Update: 96.02.15

1.	Technical Section

1.1	Purpose and Scope

Define the Generic Building Block of the Design Specification Modelling Level for dividing an enterprise or part of it into sections.

1.2	Terms and Definitions

(1)	Specified Organisation Cell: is a modelling construct inherited from the Requirements Definition Model and is the representation of an organisational area. Each Specified Organisation Cell contains at least one relationship to a Specified Organisation Unit.

1.3	Abbreviations and Acronyms

EO:	Enterprise Object

DP:	Domain Process

OC:	Specified Organisation Cell

OU:	Specified Organisation Unit

RE:	Resource

1.4	Description

1.4.1	Generalities

The aim of a Specified Organisation Cell is to specify the hierarchical structure of an enterprise or a part of it. The organisational area, that is depicted by a Specified Organisation Cell, can be of very different size (e.g., the whole enterprise, a department, a section or just the union of some jobs).

Organisation Cells defined at the Requirement Definition Modelling Level mainly covering the Model Engineering Environment are amended and new ones are created to cover the operational aspects of the enterprise model. Organisation Cells can represent any entity identified at any level of the organisation hierarchy. The Organisation Cell construct provides both the identification of its contents and its position in the hierarchy. Cell content is recognised by naming its assigned  members (Organisation Units). Position in the hierarchy is represented by the definition of the assignments of lower level cells to the current cell and its own assignment to higher level cells. The CIMOSA construct enables multidimensional organisation structures (e.g. Matrix organisations, Network organisations, others) by allowing relations to multiple higher level cells.

Identification of responsibilities and authorisation on different items (Function, Information, Resource) provides the link to other CIMOSA model views. These links will be used as escape mechanisms by identifying the organisation entity which has to take actions in case of unforeseen situations. Such situations may occur in model engineering as well as in its operational use. Through these links CIMOSA enables unambiguous assignments of responsibilities and authorisation on all enterprise entities (processes, information, resources and organisation) their assignment to organisation entities down to individual members (organisation units). Design Authority identifies the entity responsible for the engineering of a particular construct or a set of constructs. Any change or modification of these constructs has to be authorised by the assigned entity. Operational Authority/Responsibility relates to decisions to be made in the course of using the model in operational tasks (e.g. decision support, model driven operation control and monitoring). Correction on the model itself have to deferred to model engineering and falls under the Design Authority mentioned above.

Organisation Cells must have a unique identity, meaning that no two identical Organisation Cells can exist at any time. The relationships among Organisation Cells and their sub- or super-types are described as relational properties.

1.5	Description Template

Specified Organisation Cells of all types are described by the following template.

SPECIFIED ORGANISATION CELL (*)

Header
Type: Identifier: Name: Design Authority:	[relevant type - select from list; or inherited from RDM] [OC-<Unique Identifier>; RDM]] [name of Specified Organisation Cell in the form: <adjective> <noun>;  RDM <adjective> qualifying the Specified Organisation Cell <noun> related to the scope of the Specified Organisation Cell] [list of <identifier>/<name> Specified Organisation Unit and/or Organisation Cell; RDM]
Body
A. Descriptional Properties:  CELL DESCRIPTION: OPERATIONAL RESPONSIBILITY/ AUTHORISATION: Process Authorities/Responsibilities: Information Authorities/Responsibilities: Resource Authorities/Responsibilities: ORGANISATION LEVEL: B. Relational Properties: ASSIGNED ORGANISATION UNITS: ASSIGNED TO ORGANISATION  CELLS:	[textual description of the purpose of the Specified Organisation Cell;  RDM] <identifier>/<name> of Organsation Unit responsible for the Organisation Cell. Must be a person. [NIL or list of <identifier>/<name> of Function View constructs  (Domains, Domain Processes, Business Processes, Enterprise Activities, Events) for which this Specified Organisation Cell has responsibility and authority; RDM] [NIL or list of <identifier>/<name> of Information View constructs (Enterprise Objects, Object Views ) for which this Specified Organisation Cell has responsibility and authority; RDM] [NIL or list of <identifier>/<name> of Resources View constructs (Functional Entities, Resource Sets or Resource Cells) for which this Specified Organisation Cell has responsibility and authority; RDM] [Level of this Specified Organisation Cell in relation to the organisation hierarchy; RDM] [list of <identifier>/<name> of Specified Organisation Units or Organisation Cells being part of this Specified Organisation Cell; RDM] [NIL or list of <identifier>/<name> of the Specified Organisation Cells which have responsibility and authority on this Organisation Cell]
Remark: The Operational Responsibility/Authorisation entry provides the identification of the person responsible for the Organisation Cell. It must be a person. It is one of the Organisation Units assigned to this Organisation Cell.

2.	Background Section

2.1	Examples

ORGANISATION CELL:

Header
Type: Identifier: Name: Design Authority::	Production Department OC-007 'Profit Center s/v' OC-1 'Board of directors'
Body
A. Descriptional Properties:  CELL DESCRIPTION: OPERATIONAL  RESPONSIBILITY/ AUTHORISATION:    Process Authorities/     Responsibilities:    Information Authorities/     Responsibilities:    Resource Authorities/     Responsibilities: ORGANISATION LEVEL: B. Relational Properties: ASSIGNED ORGANISATION UNITS: ASSIGNED TO ORGANISATION CELL:	The scope of this Specified Organisation Cell is the production of mechanical parts (standards and variants). OU-06 'Jim Brown', 'Leader of Profit Center s/v' manufacturing process of standard products and variants  (DP-07 'Parts Manufacturing') EO-01 'Production Rate',  EO-02 'End Product', EO-04 'Part', EO-05 'Machine Tool', EO-03 'Product History', ... RE-03 'CNC Milling Machine', RE-06 'Machining Center', RE-07 'Stamping Set', RE-13 'Milling Center', RE-14 'Robot', RE-17 'Milling Cell' RE-11 'Operator', ... Second level of hierarchy  OU-06 'Leader of Profit Center s/v', others tbd OC-01 'Production Management'
2.2	Document References (none)

2.3	Open Issues

Co-ordination with the Function View (especially the work about the non-deterministic human decision making) concerning the handling of 'abnormal exceptions'. This co-ordination will concern the attributes 'Organisation Level'.

(*)	Part of Header and Body inherited from RDM Level

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Specified Organisation Unit
CIMOSA Technical Baseline

Specified Organisation Unit

B42-2200. Version: 2.2; Last Update: 96.02.15

1.	Technical Section

1.1	Purpose and Scope

Define the Generic Building Block of the Design Specification Modelling Level for the specification of the different jobs (e.g., the job description).

1.2	Terms and Definitions

(1)	Specified Organisation Unit: is a modelling construct inherited from the Requirements Definition Model. A Specified Organisation Unit is the representation of a job description (position) and as such part of an Specified Organisation Cell.

1.3	Abbreviations and Acronyms

EO:	Enterprise Object

DP:	Domain Process

OC:	Specified Organisation Cell

OU:	Specified Organisation Unit

RE:	Resource

1.4	Description

1.4.1	Generalities

The aim of a Specified Organisation Unit is to further specify the different jobs in a Specified Organisation Cell. Assignment to Specified Organisation Cells together with identification of the different types of responsibility and authority of the Specified Organisation Unit complement the job specification. Management positions are indicated in the Specified Organisation Cell.

Organisation Units defined at the Requirement Definition Modelling Level mainly covering the Model Engineering Environment are amended and new ones are created to cover all the jobs needed for the operational aspects defined in the enterprise model.

Organisation Units describe the jobs within a given hierarchical structure of an enterprise. However this only relates to the organisational aspect of the job, those tasks which have to be done in relations to the responsibilities and authority assigned to the particular Organisation Unit. The construct enables listing of the requirements in terms of the Skill Profile needed to serve the assigned task. These tasks may be both in the model engineering and the operational environment of the enterprise. For the latter tasks the assignments may not become known until system design has progressed to a rather advanced state. Therefore those requirements have to be gathered during the design phase demonstrating the iterativity of the model engineering process.

The Organisation Unit may be modelled as one or several Functional Entities in performing certain tasks in the enterprise operation. These roles will also be identified in this modelling construct.

Design Authority identifies the entity responsible for the engineering of a particular construct or a set of constructs. Any change or modification of these constructs has to be authorised by the assigned entity. Operational Authority/Responsibility relates to decisions to be made in the course of using the model in operational tasks (e.g. decision support, model driven control and monitoring). Correction on the model itself have to deferred to model engineering and falls under the Design Authority mentioned above.

Organisation Units must have a unique identity, meaning that no two identical Organisation Units can exist at any time. The relationships among Organisation Units and their sub- or super-types are described as relational properties by means of Organisation Relationships Management positions are indicated in the specific Organisation Cell.

1.5	Description Template

Specified Organisation Units of all types are described by the following template.

SPECIFIED ORGANISATION UNIT (*)

Header
Type: Identifier: Name: Design Authority:	[relevant type - select from list; or inherited RDM] [OU-<Unique Identifier>; RDM] [name of Specified Organisation Unit in the form: <adjective> <noun>;  RDM <adjective> qualifying the Specified Organisation Unit <noun> related to the scope of the Specified Organisation Unit] [list of <identifier>/<name> of Specified Organisation Unit and/or Organisation Cell; RDM]
Body
A. Descriptional Properties:  UNIT JOB DESCRIPTION: SKILL PROFILE: Owners of job: RESPONSIBILITIES: AUTHORITIES: FUNCTIONAL ENTITY: B. Relational Properties: ASSIGNED TO ORGANISATION CELL:	[textual description of decision-making or problem-solving tasks; RDM] [list of Capabilities which are needed to fulfil the job; RDM] [list <identifier/name> of Humans holding the job; new entry] [list of <identifier>/<name> of responsibility given to this Specified Organisation Unit; RDM] [list of <identifier>/<name> of authority necessary to fulfil the job; RDM] [list of <identifier>/<name> of Functional Entity associated to this Specified Organisation Unit] [<identifier>/<name> of the Specified Organisation Cell which has responsibility and authority on this Organisation Unit]
2.	Background Section

2.1	Examples

ORGANISATION UNIT

Header
Type: Identifier: Name: Design Authority:	Organisation Unit/Management OU-001 'Manager of Profit Center s/v' OC-1 'Board of Directors'
Body
A. Descriptional Properties:  UNIT JOB DESCRIPTION: SKILL PROFILE: Owner of job: RESPONSIBILITIES: AUTHORITIES: FUNCTIONAL ENTITY: B. Relational Properties: ASSIGNED TO ORGANISATION CELL:	job description of the leader of the Profit Center standard/variants Leadership, Experience in mechanical part manufacturing Operational planning, Department budgeting, ... John Smith Operation of Profit Center (department internal processes and resources) organisational authority for all collaborators and all department internal planning FE-03 'Manager' (OC-007 'Profit Center s/v') OC-007 Profit Center s/v
2.2	Document References (none)

2.3	Open Issues (none)

(*)	Part of Header and Body inherited from RDM Level

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Specified Organisation Element
CIMOSA Technical Baseline

Specified Organisation Element

B42-2300. Version: 2.2; Last Update: 96.02.15

1.	Technical Section

1.1	Purpose and Scope

Define the Generic Building Block of the Design Specification Modelling Level for the representation of partial work elements an Specified Organisation Unit has to fulfil.

1.2	Terms and Definitions

(1)	Specified Organisation Element: represents an area of responsibility as well as an area of authority of a part of a job description, which represents the atomic level of the Organisation View. The construct offers the possibility to specify different degrees of responsibility and authority for the different Specified Organisation Elements.

1.3	Abbreviations and Acronyms (none)

1.4	Description

1.4.1	Generalities

An Organisation Element is an item of an indivisible or atomic item of an organisation and represents the lowest level of granularity of modelling in the CIMOSA Organisation View. These Elements can be defined by the user according to his needs. At least, the following types are identified:

-	Responsibility

-	Authority

-	Decision Level

-	Skill Profile

Organisation Elements are used to describe properties of Organisation Units.

1.4.2.	General Constraints

- 	Only meaningful Organisation Elements with a concrete reality for the Organisation must be defined in the Organisation view.

1.5	Description Template (not applicable)

2.	Background Section

2.1	Examples (none)

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Function View, Implementation Description Modelling Level
CIMOSA Technical Baseline

Function View,

Implementation Description Modelling Level

B13-1000. Version: 0.2; Last Update: 94.01.14

1.	Technical Section

1.1	Purpose and Scope

Provides the Function View constructs at the Implementation Description Modelling Level and their relationships as required by the CIM system implementers.

1.2	Terms and Definitions

(1)	Function View, Implementation Description Modelling Level:

(a)	is the Function View of the Implementation Description Modelling Level as defined in the European Pre-Norm (ENV 40 003).

(b)	consists-of

-	non-empty-set-of Generic Building Blocks and set-of Building Block Types for Implementation Description in the Function View and

-	set-of Partial Implementation Description Models for the Function View and

-	one Particular Implementation Description Model for the Function View.

1.3	Abbreviations and Acronyms

CEN: 	Comité Européen de Normalisation

ENV: 	European pre-Norm

CIM:	Computer Integrated Manufacturing

1.4	Description

The CIMOSA Function View is described by Function View Modelling Paradigms. The Implementation Description Modelling Level of the Function View is made of three sub-parts:

1.	The Generic Implementation Description Building Blocks which form a structured catalogue of all Generic Building Blocks and Building Block Types of the Function View used for Implementation Description;

2.	The Partial Implementation Description Models which make up a structured catalogue of classified, (partially) instantiated aggregations of Function View generic constructs used to instantiate Particular Implementation Description Models;

3.	The Particular Implementation Description Model which contains the description of all implemented constructs for the Function View of one individual enterprise.

At the Implementation Description Modelling Level the Function View describes:

-	implementation and run-time information for control of Domain and Business Processes, their Enterprise Activities and Events;

-	connections of a Particular Architecture of an Enterprise with its real-world environment.

Since manufacturing systems are prone to many random events perturbating their operations, an important issue to be addressed at the implementation level is exception handling. The model must be able to detect abnormal situations and react to these. When this is not possible or has not been foreseen but is detected by the services of the Integrating Infrastructure executing the model, control is passed to the responsible entity of the current process identified in the Organisation View. At this level, physical input and output connections of the model with real-world entities must be defined. They are called ports.

The Function View of the Implementation Description Model of a Particular Architecture of an enterprise will be used by services of the Business Entity of the CIMOSA Integrating Infrastructure to control and monitor the execution of the business processes integrated by CIMOSA.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	ENV 40 003: Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling. CEN/CENELEC, 1990.

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Generic Building Blocks of the Function View, Implementation Description Modelling Level
CIMOSA Technical Baseline

Generic Building Blocks of the Function View,

Implementation Description Modelling Level

B13-2000. Version: 0.5; Last Update: 96.03.01

1.	Technical Section

1.1	Purpose and Scope

Provides the list of Generic Building Blocks of the Function View to be used in the CIMOSA Reference Architecture and the Particular Architecture for the implementation description of CIM systems.

1.2	Terms and Definitions

(1)	Generic Building Blocks of the Function View, Implementation Description Modelling Level (ENV 12 204):

(a)	are used to build Partial Implementation Description Models and Particular Implementation Description Models of business operations of an enterprise.

(b)	the set of Generic Building Blocks and Building Block Types of the Function View consists-of:

-	Objective/Constraint - O/C

-	Implemented Domain - DM

-	Implemented Domain Process - DP

-	Implemented Business Process - BP

-	Implemented Enterprise Activity - EA

-	Implemented Event - EV

(c)	the set of Generic Building Blocks components of the Function View consists-of:

-	Implemented Process Behaviour

-	Implemented Activity Behaviour

-	Implemented Functional Operation - FO

1.3	Abbreviations and Acronyms

AID: 	AMICE Implementation Description language

CIM:	Computer Integrated Manufacturing

1.4	Description

Figure B13-2000/1: Generic Building Blocks of the Function View and their Relationship at the Implementation Description Modelling Level

The CIMOSA Generic Building Blocks of the Function View at the Implementation Description Modelling Level are used to build up the CIMOSA Function View Modelling Paradigm at this Modelling Level (see Figure 2000/1). In the Function View of the Implementation Description Modelling Level CIMOSA describes in a formal, implementation dependent, way what has to be done in the enterprise and how this will be done in terms of Implemented Domains, Implemented Events, Implemented Domain Processes, Implemented Business Processes and Implemented Enterprise Activities. All these Generic Building Blocks inherit or overwrite properties of equivalent Generic Building Blocks of the Design Specification Modelling Level.

The Process Behaviour of Implemented Domain Processes and Business Processes and the Activity Behaviour of Implemented Enterprise Activities are defined in terms of the AID (AMICE Implementation Description) language [1]. Further implementation details are added to constructs at this Modelling Level as follows:

Implemented Domains are used to define the context of a set of Implemented Domain Processes, defining the data types for global variables, constants, message types to be exchanged by Implemented Enterprise Activities, channels for communications, and input/output ports as connection points between the model and the real-world environment. This construct allows the modular definition of a full Implementation description Model, each Domain being a module which can be described (and compiled) separately.

Implemented Events are provided with a strict triggering condition (a predicate) indicating under which circumstances their occurrences can be created, a priority, and eventually an input/output port in addition to their classical properties.

Implemented Domain Processes are essentially defined by their triggering Events, their priority (to resolve execution conflicts) and their set of Behavioural Rules defining their Process Behaviour. Exception handling mechanisms need to be defined to deal with random events or unexpected errors during execution.

Implemented Business Processes inherit a priority from their parent Domain Process, they may have a Resource Input as defined at the Design Specification Modelling Level and are characterised by their Process Behaviour. Notice that this construct is only provided for convenience, i.e. to factories pieces of behaviour which can be re-used in the model. Indeed, once the model is complete, each Implemented Domain Process is equivalent to a graph of Implemented Enterprise Activities. Exception handling mechanisms can also be defined at this level.

Implemented Enterprise Activities are used to federate CIMOSA models in the sense that they make the link among constructs of the various CIMOSA Views. In addition to their usual entries, they are provided with properties concerning input/output channels, their interrupt ability, their pre-emption and exception handling mechanisms in their Activity Behaviour. Furthermore, indication must be given about input/output ports for their Function Input, Function Output and Control Input so that the right Presentation Services can be implemented.

Objective/Constraint is a common Generic Building Block of the Function View defined in B11-series of items.

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Implemented Domain
CIMOSA Technical Baseline

Implemented Domain

B13-2100. Version: 0.4; Last Update: 96.03.01

1.	Technical Section

1.1	Purpose and Scope

Provides the implementation description of a Domain of an enterprise.

1.2	Terms and Definitions (none)

(1)	Implemented Domain:

(a)	provides the implementation description of a CIMOSA Domain. It defines the execution environment of a set of Domain Processes for a part of the enterprise.

(b)	is the description of a CIMOSA Domain in the Function View of the Implementation Description Model. This construct provides a "Table of Contents" for the part of the enterprise being analysed, providing the list of constructs making up the Domain for the purpose of model design, simulation and validation.

(c)	is a construct inherited from the Requirements Definition Model and Design Specification Model used to establish the content and the boundary of the part of the enterprise which is subject to CIMOSA analysis based on a given set of business objectives and constraints (Domain Objectives and Domain Constraints). It is made of a set of interacting Implemented Domain Processes, Implemented Events and Implemented Object Views (information objects and physical objects including resources).

1.3	Abbreviations and Acronyms

AID: 	AMICE Implementation Description language

DSM: 	Design Specification Model

DM:	Domain

DP:	Domain Process

EV:	Event

OC:	Organisation Cell

PIDM: 	Particular Implementation Description Model

RDM:	Requirements Definition Model

O/C:	Objective/Constraint

OV:	Object View

OU:	Organisation Unit

RL:	Domain Relationship

1.4	Description

An Implemented Domain is the representation of a CIMOSA Domain in the Function View of an Implementation Description Model. It inherits properties from the equivalent Specified Domain defined in the Design Specification Model. The purpose of this construct is to structure the model into manageable and consistent pieces to break down global system complexity.

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Implemented Domain instances of all types are described by the following template:

IMPLEMENTED DOMAIN (*)

Header
Type: Identifier: Name: Design Authority:	[relevant category - select from list; inherited from Domain definition in RDM/DSM] [DM-<unique identifier>; RDM/DSM] [name of Specified Domain in the form: <adjective> <noun>, where <noun> relates to the functionality, <adjective> relates to the scope; RDM/DSM] [<identifier> / <name> of Implemented Organisation Unit and/or Organisation Cell with authority for this particular instance; RDM/DSM]
Body
A. Descriptional Properties:  DESCRIPTION: CIMOSA COMPLIANT: DOMAIN COMPONENTS DOMAIN OBJECTIVES: DOMAIN CONSTRAINTS: DOMAIN PROCESSES: OBJECT VIEWS: B. Relational Properties: BOUNDARY: EVENTS:	[textual description; RDM/DSM] ['yes' or 'no'] [non-empty list of <identifier> / <name> of Objective/ Constraint; RDM/DSM] ['NIL' or list of <identifier> / <name> of Objective/ Constraint; RDM/DSM] [non-empty list of <identifier> / <name> of Implemented Domain Process instances possessed by this Implemented Domain instance, RDM/DSM] [non-empty list of <identifier> / <name> of Implemented Object Views instances received or sent by occurrences of this Implemented Domain instance, RDM/DSM] [non-empty list of <identifier> / <name> of Domain Relationship instances between this Domain instance and other Domain instances. Can be left empty for partial instances] [non-empty list of <identifier> / <name> of instances of Implemented Events received, sent or received by occurrences of this Implemented Domain instance, RDM/DSM]
2.	Background Section

2.1	Examples

IMPLEMENTED DOMAIN

Header
Type: Identifier: Name: Design Authority:	Shop-Floor Operations/Batch-oriented DM-01 'Flexible Manufacturing Shop' OC-001 'Manufacturing Engineering'
Body
A. Descriptional Properties:  DESCRIPTION: CIMOSA COMPLIANT: DOMAIN COMPONENTS DOMAIN OBJECTIVES: DOMAIN CONSTRAINTS: DOMAIN PROCESSES: OBJECT VIEWS: B. Relational Properties: BOUNDARY: EVENTS:	'Flexible Manufacturing Shop': Domain assigned to the Production of batches of parts with a medium degree of commonality (cylindrical shape, hard material), employing a set of metalworking machines and similar processing. yes O/C-01 'Objective of Flexibility' O/C-02 'Objective of Cycle-Time' O/C-11 'Constraint on Resources' DP-01 'Order Management' DP-02 'Exception Management' OV-001 'Workstation' OV-002 'Manufacturing Order' RL-01 'Order Release' RL-02 'Shop Condition' EV-01 'Order Management Request' EV-02 'Machine Failure'
2.2	Document References (none)

2.3 	Open Issues (none)

(*)	Part of Header and Body inherited from RDM/DSM Level

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Implemented Domain Process
CIMOSA Technical Baseline

Implemented Domain Process

B13-2200. Version: 0.3; Last Update: 96.03.01

1.	Technical Section

1.1	Purpose and Scope

Defines the implementation description of Domain Processes of an enterprise.

1.2	Terms and Definitions (none)

(1)	Implemented Domain Process:

(a)	is a modelling construct used to represent a Domain Process as it stands at the top of a functional decomposition within a Implemented Domain of the Implementation Description Model. Its set of Behavioural Rules (*) is described in terms of a Implemented Process Behaviour specification.

(b)	is a construct inherited from the Requirements Definition Model and Design Specification Model triggered by means of at least one Implemented Event and nothing else than Events and producing defined end results (Function Output). It encapsulates a well-defined set of enterprise functionalities and behaviour (i.e. Implemented Functional Operation, Implemented Enterprise Activity and Implemented Business Process) to realise clearly defined objectives under given constraints (Objective/Constraint).

(c)	receives input from and/or provides output to other Implemented Domain Processes. It is only used by one Implemented Domain, i.e. it is not used either by any other Implemented Domain or Implemented Business Process, and therefore is at the top of a functional decomposition hierarchy.

1.3	Abbreviations and Acronyms

AID: 	AMICE Implementation Description language

RDM:	Requirements Definition Model

BP:	Business Process

DM:	Domain

DP:	Domain Process

DR:	Declarative Rule

EV:	Event

DSM: 	Design Specification Model

PIDM:	Particular Implementation Description Model

ES:	Ending State

O/C:	Objective/Constraint

OC:	Organisation Cell

OV:	Object View

1.4	Description

The purpose of this construct is to describe Domain Processes at the Implementation Description Modelling Level, and especially to indicate resource requirements related to this process in terms of Resource Units. A Resource Unit is a Resource occurrence. If one or more Resource Units are listed as Resource Input, this means that the Resource Units will be acquired and hold for the whole duration of the Domain Process occurrence once started. In this case a process duration is required to plan resource allocation.

A priority (in the range 1 to 6 where 1 means lowest priority and 6 means highest priority) is arbitrary given by users to each Domain Process instance, which is then inherited by each Domain Process occurrence of this class. This priority will be used at run-time to solve conflicting access of different Domain Processes on the Resource Units. The priority is inherited by Business Processes and Enterprise Activities of the Domain Process. Therefore, no priority is defined in the model for Business Processes and Enterprise Activities. The Implemented Process Behaviour defining the set of Behavioural Rules of the Implemented Domain Process is expressed using the syntax of the AID language [1].

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Implemented Domain Process instances of all types are described by the following template:

IMPLEMENTED DOMAIN PROCESS (**)

Type:
Identifier:  Name: Design Authority: Operation Responsibility: Operation Authority:	[relevant category - select from list <name>; inherited from RDM/DSM] [DP-<Unique Identifier>; RDM/DSM]  [name of Domain Process instance in the form: <adjective> <noun>  <adjective>: qualifying the Domain Process instance  <noun>: related to the scope of the Domain Process; RDM/DSM] [<identifier> / <name> of Implemented Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance; RDM/DSM] [<identifier> / <name> of Implemented Organisation Unit and/or Organisation Cell with responsibility on this instance, DSM] [<identifier> / <name> of Implemented Organisation Unit and/or Organisation Cell with authority for operation of this instance, DSM]
Body
A. Descriptional Properties:  OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION: INPUTS    FUNCTION INPUT:    CONTROL INPUT:    RESOURCE INPUT: OUTPUTS    FUNCTION OUTPUT:    CONTROL OUTPUT:    RESOURCE OUTPUT: PROCESS BEHAVIOUR: PRIORITY: EXCEPTION HANDLING: B. Relational Properties: WHERE USED: COMPRISES: EVENTS:	[non-empty list of  <identifier> / <name> of Objective/ Constraint; RDM/DSM] ['NIL' or list of <identifier> / <name> of Objective/ Constraint; RDM/DSM] ['NIL' or list of <identifier> / <name> of Declarative Rule instances applicable to this Domain Process instance;] [textual description; RDM/DSM] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Specified Object View instances, occurrences of which are processed by activities of the process; RDM/DSM] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Specified Object View instances, occurrences of which are used but not processed by activities of this process; RDM/DSM] ['NIL' or list of <identifier> / <name> of Resource Units to be acquired and hold for the full duration of the execution of the occurrences of this Domain Process instance, DSM] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Specified Object View instances, occurrences of which are produced by activities of this process; RDM/DSM] ['NIL' or list of <identifier> / <name> of Specified Event instances, occurrences of which could be generated during the course of occurrences of this Specified Domain Process instance; RDM/DSM] ['NIL' or list of <identifier> / <name> of Specified Object View instances, which could be generated during the course of occurrences of this Domain Process instance; RDM/DSM] [exact non-empty set of Behavioural Rules RDM/DSM, expressed using the syntax defined for Process Behaviour in the AID language] [integer between 1 and 6 (1: lowest priority; 6: highest priority). By default, 6; DSM] [exception handling mechanisms applicable to occurrences of this Domain Process instance and described according to the syntax of AID; new entry (***)] [<identifier> / <name> of Implemented Domain employing this Implemented Domain Process. RDM/DSM] [non-empty list of <identifier / <name> of all next lower level Implemented Business Processes and Implemented Enterprise Activities instances that are employed by this Implemented Domain Process. RDM/DSM] [non-empty list of <identifier> / <name> of Implemented Event instances, occurrences of which are required to trigger occurrences of this Implemented Domain Process instance. RDM/DSM]
Nota: Description, objectives, constraints, Declarative Rules as well as inputs/outputs can be inherited from the Design Specification Modelling Level but they are not processed in the Enterprise Operation Environment.

2.	Background Section

2.1	Examples

IMPLEMENTED DOMAIN PROCESS

Header
Type: Identifier:  Name: Design Authority: Operation Responsibility: Operation Authority:	Shop Floor Operation/Batch Oriented DP-5 'Gearbox Assembly' OC-001 'Manufacturing Engineering' OC-007 'Profit Center s/v' OC-007 'Profit Center s/v'
Body
A. Descriptional Properties:  OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION: INPUTS    FUNCTION INPUT:    CONTROL INPUT:    RESOURCE INPUT: OUTPUTS    FUNCTION OUTPUT:    CONTROL OUTPUT:    RESOURCE OUTPUT: PROCESS BEHAVIOUR: PRIORITY: EXCEPTION HANDLING: B. Relational Properties: WHERE USED: COMPRISES: EVENTS:	O/C-90 'Grant Production Plan at Gearbox Assembly Level O/C-91 'Constraint of Resources and Cost DR-90 'Balance Gearbox Assembly Line between Push and Pull Concept DP-5-'Gearbox Assembly' models the assembly area for gearbox production consisting of the technological production system and the  production management system. OV-090 'Part' (Purchased parts, components and Sub-assemblies) OV-091 'Status information - old' RE-18 'Assembly Line' OV-092 'Gearbox' (Finished product) OV-093 'Manufacturing Order' (pull) OV-094 'Status information - new' NIL WHEN (START WITH Event EV-44 'Gearbox Assembly Order') DO BP-5.1 & BP-5.2 & BP-5.3 & BP-5.4 & BP-5.5 WHEN (ES(BP-5.1)= 'Case Completed') AND (ES(BP-5.2)= 'Differential Completed') AND (ES(BP-5.3)= 'MShaft Completed') AND (ES(BP-5.4)= 'AShaft Completed') AND (ES(BP-5.5)= 'Kit Completed') DO BP-5.6 WHEN (ES(BP-5.6)= 'Final Assembly Completed') DO FINISH (*issue Event-45*) WHEN (ES(BP-5.x)= 'not Completed') DO 'Exception Handling'  (*issue Event-25*) 6 (1: lowest priority; 6: highest priority). Transfer Control = close Domain Process DP-5 'Gearbox Assembly' DM-1 'Gearbox Production' BP-5.1 'Case, Produce by Line' BP-5.4 'AShaft, Produce by Line BP-5.2 'Diff, Produce by Line' BP-5.5 'Kit, Produce by Line BP-5.3 'Mshaft, Produce by Line' BP-5.6 'Gearbox Final Assembly' EV-44 'Order' from DP-4 'Component Storage' EV-45 'Order' to DP-6 'Deliver Product' EV-25 'Request for 'Exception Handling'
2.2	Document References (none)

2.3	Open Issues (none)

(*)	Previously called Procedural Rule; renamed to avoid inconsistency with public meaning of term Procedural Rule.

(**)	Part of Header and Body inherited from RDM/DSM Level

(***)	Body additional entries at IDM Level

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Implemented Process Behaviour
CIMOSA Technical Baseline

Implemented Process Behaviour

B13-2210. Version: 0.4; Last Update: 96.03.01

1.	Technical Section

1.1	Purpose and Scope

Provides a language to describe Business Process and Domain Process behaviour (i.e. their set of Behavioural Rules) at the Implementation Description Modelling Level.

1.2	Terms and Definitions

(1)	Implemented Process Behaviour: represents the flow of control governing the behaviour of Implemented Domain Processes or Implemented Business Processes of the Implementation Description Model. It is made of a set condition-action rules for each process. The following set of condition-action rules has been defined:

-	process triggering

-	forced

-	conditional

-	spawning

-	rendezvous

-	looping

-	completion

-	run-time choice

-	unordered set

1.3	Abbreviations and Acronyms (none)

1.4	Description

1.4.1	Generalities

Implemented Process Behaviour is the part of an implemented process (Domain Process or Business Process) which describes how to control the execution of employed Business Processes and/or Enterprise Activities using their Ending Status values in the Function View of the Implementation Description Model. It is derived from the specification of the Process Behaviour of the associated process as defined at the Design Specification Modelling Level and is made of a set of condition-action rules expressed using the AID language syntax [1].

1.4.2	Process Behaviour Description

Process Behaviour is defined as an unordered set of condition-action rules.

Important Remark: Only one rule in a Process Behaviour can be fired at any time.

Definition: A rule can be fired when its condition clause evaluates to true. Firing a rule results in the activation of actions specified in its action clause.

Each rule is defined by:

-	a condition clause and

-	an action clause

and has the following syntax:

-	WHEN <condition> DO <action>

The action part represents an Implemented Business Process or an Implemented Enterprise Activity. The syntax of Implemented Process Behaviour in Backus-Naur form is defined as follows:

<Process-Behaviour> ::= "{" <Rule-set> "}"

<Rule-set> ::= <Rule> | <Rule> <Rule-set>

<Rule> ::=  "WHEN" "(" <Condition-clause> ")" "DO" <Action-clause>

<Condition-clause> ::= <Cond> | <Cond> "AND" <Condition-clause>

<Cond> ::= "START" | "START" "WITH" <EventCond> | <CondExp>

<CondExp> ::= <exp> | <exp> "AND" <CondExp>

<exp> ::= "ES" "(" <Function-name> ")" "=" <value> | "ES" "(" <Function-name> ")" "=" "any" | <EventCond>

<EventCond> ::= <Event-name> | <Event-name> "AND" <EventCond>

<value> ::= string

<Action-clause> ::= <Function-name> | <Spawning> | <Choice> | "FINISH"

<Spawning> ::= <Function-name> "&" <Other-Spawning>

<Choice> ::= <Function-name> "|" <Other-Choice>

<Other-Spawning> ::= <Function-name> | <Function-name> "&" <Other-Spawning>

<Other-Choice> ::= <Function-name> | <Function-name> "|" <Other-Choice>

<Function-name> ::= identifier (* must be the identifier of a Business Process or of an Enterprise Activity *)

If proved necessary, the syntax of the condition clause could be significantly extended in the future to deal with variables in expressions of the clause. This is not done in the current version of CIMOSA to enforce the principle of separation of function and control.

2.	Background Section

2.1	Examples

Examples of valid rules are:

- To start the set of rules of a Business Process:  	WHEN (START) DO EA-1 & EA-2

- To start a Domain Process by an Event: 	WHEN (START WITH Event) DO BP-1

- To start a Domain Process by a conjunction of two Events:

WHEN (START WITH Event 1 AND Event 2)

DO BP-1

- To wait for EA-1 with status 'value1' to trigger BP-5: 	WHEN (ES(EA-1) = value1) DO BP-5

- To combine ending status's and events to trigger a set actions in parallel:

WHEN (ES(EA-1) AND ES(BP-3) AND Event 1)

DO BP-4 & EA-6

- To finish a set of rules:	WHEN (ES(EA-4) = value1) DO FINISH

- To finish a set of rules whatever the Ending Status of EA-4: 	WHEN (ES(EA-4) = any) DO FINISH

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Implemented Business Process
CIMOSA Technical Baseline

Implemented Business Process

B13-2300. Version: 0.4; Last Update: 96.03.01

1.	Technical Section

1.1	Purpose and Scope

Defines the implementation description of Business Processes of an enterprise.

1.2	Terms and Definitions (none)

(1)	Implemented Business Process:

(a)	is a modelling construct inherited from the Requirements Definition Model and Design Specification Model used to represent a Business Process within an Implementation Description Model. Its set of Behavioural Rules (*) is described in terms of an Implemented Process Behaviour specification.

(b)	may have a functional part defined, and must have a behaviour part and a structure part. It is employed by one or more Domain Processes and/or Business Processes and it employs one or more Business Processes and/or Implemented Enterprise Activity(ies). It is triggered by a parent structure (Implemented Domain Process or Business Process).

1.3	Abbreviations and Acronyms

AID: 	AMICE Implementation Description language

DSM: 	Design Specification Model

BP:	Business Process

DP:	Domain Process

DR:	Declarative Rule

ES:	Ending Status

PIDM: 	Particular Implementat. Description Model

RDM: 	Requirements Definition Model

O/C:	Objective/Constraint

OC:	Organisation Cell

OV:	Object View

RE:	Resource

1.4	Description

The purpose of this construct is to describe Business Processes at the Implementation Description Modelling Level, and especially to indicate resource requirements related to this process in terms of Resource Units. A Resource Unit is a Resource occurrence. If one or more Resource Units are listed as Resource Input, this means that these Resource Units must be acquired and hold for the whole duration of the Business Process occurrence. Of course, it not necessary to repeat here the Resource Units required by the parent Domain Process. In this case a process duration is required to plan resource allocation.

Last EA's on BP ending	Ending status of BP
only one EA	= ending status of EA
EA-x or EA-y	= ending status of EA-x or EA-y
EA-x and EA-y	= ending status of EA-x and EA-y
Remark: Business Processes are like subprograms or procedures in procedural programming languages. They represent "reusable pieces of code". They only exist to modularise the model of the enterprise behaviour (and to factorize pieces of the model to reduce its size) but have no true existence on their own. Their ending status function must be a logical function of the ending status's of the Enterprise Activities used within them defined as follows:

The Implemented Process Behaviour defining the set of Behavioural Rules of the Implemented Business Process is expressed using the syntax of the AID language [1].

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Implemented Business Process instances of all types are described by the following template:

IMPLEMENTED BUSINESS PROCESS (**)

Type:	[relevant category - select from list <name>; inherited from Business Process instance definition in RDM/DSM]
Identifier: Name: Design Authority: Operation Responsibility: Operation Authority:	[BP-<Unique Identifier>; RDM/DSM] [name of Business Process instance in the form: <adjective> <noun>  <adjective>: qualifying the Business Process instance  <noun>: related to the scope of the Business Process;  RDM/DSM] [<identifier> / <name> of Implemented Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance; RDM/DSM] [<identifier> / <name> of Implemented Organisation Unit and/or Organisation Cell with responsibility on this instance, inherited from DSM] [<identifier> / <name> of Implemented Organisation Unit and/or Organisation Cell with authority for operation of this instance,  DSM]
Body
A. Descriptional Properties:  OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION: INPUTS    FUNCTION INPUT:    CONTROL INPUT: RESOURCE INPUT: OUTPUTS    FUNCTION OUTPUT:    CONTROL OUTPUT:    RESOURCE OUTPUT: ENDING STATUSES: PROCESS BEHAVIOUR: EXCEPTION HANDLING: MIN PROCESS DURATION: MAX. PROCESS DURATION:  B. Relational Properties: WHERE USED: COMPRISES:	[non-empty list of  <identifier> / <name> of Objective/ Constraint; inherited from RDM/DSM] ['NIL' or list of <identifier> / <name> of Objective/ Constraint; RDM/DSM] ['NIL' or list of <identifier> / <name> of Declarative Rule instances applicable to this Domain Process instance; RDM/DSM] [textual description; RDM/DSM] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Specified Object View instances, occurrences of which are processed by activities of the process; RDM/DSM] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Specified Object View instances, occurrences of which are used but not processed by activities of this process; RDM/DSM] ['NIL' or list of <identifier> / <name> of Resource Units required for the full duration of occurrences of this Business Process instance, inherited from DSM] ['NIL' or list of <identifier> / <name> (eventually preceded by 'STREAM OF') of Specified Object View instances, occurrences of which are produced by activities of this process; RDM/DSM] ['NIL' or list of <identifier> / <name> of Specified Event instances, occurrences of which could be generated during the course of occurrences of this Specified Domain Process instance; RDM/DSM] ['NIL' or list of <identifier> / <name> of Specified Object View instances, which could be generated during the course of occurrences of this Domain Process instance; RDM/DSM] [non-empty list of all possible values (defined as a function of the ending status's of employed Implemented Enterprise Activities) and their description (text) for the Ending Status of occurrences of this Implemented Business Process instance. RDM/DSM levels. Syntax given by AID] [non-empty set of Behavioural Rules ; RDM/DSM. expressed using the syntax defined for Process Behaviour in the AID language] [exception handling mechanisms applicable to occurrences of this Domain Process instance and described according to the syntax of AID; new entry (***)] [minimum duration of occurrences of this Business Process instance; new entry] [maximum duration of occurrences of this Business Process instance; new entry] [non-empty list of <identifier> / <name> of Implemented Domain Process and/or Business Process instances employing this Implemented Business Process instance. RDM/DSM] [non-empty list of <identifier> / <name> of all next lower level Implemented Business Process instances and Implemented Enterprise Activity instances that are employed by this Implemented Business Process instance. RDM/DSM]
Nota: Description, objectives, constraints, Declarative Rules as well as inputs/outputs can be inherited from the Design Specification Modelling Level, but are not processed in the Enterprise Operation Environment.

2.	Background Section

2.1	Examples

IMPLEMENTED BUSINESS PROCESS

Header
Type: Identifier: Name: Design Authority: Operation Responsibility: Operation Authority:	Shop Floor Operation/Batch Oriented BP-5.1 'Case Completed' OC-001 'Manufacturing Engineering' OC-007 'Profit Center s/v' OC-007 'Profit Center s/v'
Body
A. Descriptional Properties:  OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION: INPUTS    FUNCTION INPUT:    CONTROL INPUT:    RESOURCE INPUT: OUTPUTS    FUNCTION OUTPUT:    CONTROL OUTPUT:    RESOURCE OUTPUT: PROCESS BEHAVIOUR: EXCEPTION HANDLING: MIN PROCESS DURATION: MAX. PROCESS DURATION:  B. Relational Properties: WHERE USED: COMPRISES:	O/C-90 'Grant Production Plan at Case Assembly Level O/C-91 'Constraint of Resources and Cost NIL BP-5.1-'Case Completed' models the case assembly area for the gearbox production consisting of the technological production system. OV-095 'Part' (Purchased parts, components) OV-096 'Status information - old' RE-19 'Case Assembly Line' OV-096 'Case' (Subassembly) OV-097 'Manufacturing Order' (pull) OV-098 'Status information - new' NIL WHEN (START WITH Event EV-44 'Gearbox Assembly Order')  DO BP-5.1 WHEN (ES(BP-5.1)= 'Case Completed') DO BP-5.6 WHEN (ES(BP-5.1)= 'not Completed') DO 'Exception Handling'  (*issue Event-25*) Transfer Control = close Domain Process DP-5 'Gearbox Assembly' 4 Hours per Batch 6 Hours per Batch DP-5 'Gearbox Assembly' tbd
2.2	Document References (none)

2.3	Open Issues (none)

(*)	Previously called Procedural Rule; renamed to avoid inconsistency with public meaning of term Procedural Rule.

(**)	Part of Header and Body inherited from RDM/DSM Level

(***)	Body additional entries at IDM Level

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Implemented Enterprise Activity
CIMOSA Technical Baseline

Implemented Enterprise Activity

B13-2400. Version: 0.5; Last Update: 96.03.01

1.	Technical Section

1.1	Purpose and Scope

Defines the implementation description of Enterprise Activities of an enterprise.

1.2	Terms and Definitions (none)

(1)	Implemented Enterprise Activity: is a modelling construct inherited from the Requirements Definition Model and Design Specification Model used to represent functionalities within an Implemented Domain and as part of an Implemented Domain Process of the Implementation Description Model. It transforms its Function Input into Function Output using Control Input and Resource Input according to its Implemented Activity Behaviour. The Activity Behaviour specification indicates how Implemented Functional Operations are employed to realise the functionality of the Enterprise Activity.

1.3	Abbreviations and Acronyms

AID: 	AMICE Implementat. Description language

DSM: 	Design Specification Model

CS:	Capability Set

DR:	Declarative Rule

EA:	Enterprise Activity

ES:	Ending Status

FE:	Functional Entity

PIDM: 	Particular Implementat. Description Model

RDM: 	Requirements Definition Model

OC:	Organisation Cell

O/C:	Objective/Constraint

OV:	Object View

OU:	Organisation Unit

1.4	Description

1.4.1	Generalities

The purpose of this construct is to describe Enterprise Activities at the Implementation Description Modelling level. The construct inherits or overwrites entries defined at previous modelling levels (Requirements Definition Modelling Level and Design Specification Modelling Level). Enterprise Activities describe pieces of enterprise functionality and therefore use a different language than Domain/Business Processes to describe their behaviour using Functional Operations.  Since actions are performed at the activity level, the activities are in most cases connected with the real-world environment via entry/exit points, called input and output ports, which receive/send their Events and/or Object Views (physical or information). Ports are defined on the Object Views in the Function Input, Function Output, Control Input and Control Output of the Enterprise Activity.

Furthermore, messages, i.e. predefined sequences of bytes, can be exchanged by activities to communicate for synchronisation purposes. The concept of channels, i.e. a logical name representing a communication means, is planned to support this. Functional Operations are like calls (or requests) to Functional Entities (i.e. active Resource Units) to perform actions according to some algorithm (specified by their Implemented Activity Behaviour). This algorithm may require the use of variables which can be declared locally in the Enterprise Activity or globally in the Domain description. The right list of arguments with correct data types must be provided to Functional Operations. Indication of input parameters and output parameters is necessary.

Functional Operations are not pre-emptive. They cannot be suspended and later be restarted. They can only be cancelled in very special cases by the CIMOSA Integrating Infrastructure (system breakdown, process failure, etc.). After their execution, a status code (of type FO status) must be available and can be used in the algorithm of the employing Enterprise Activity. This code value can be used in the calling Enterprise Activity using the status code variable.

Two ways for using Functional Operations in Enterprise Activities are allowed:

-	early binding: This means that only one Functional Entity (a Resource Unit) is specified for the Functional Operation, meaning that all occurrences of this Functional Operation will be performed by this Resource Unit only

-	late binding: This means that more than one Functional Entities (Resource Units) are specified for the Functional Operation, meaning that any time an occurrence of this Functional Operation has to be executed, the run-time system has to decide which Functional Entity has be allocated for this occurrence.

The syntax and semantics of each entry of the Implemented Enterprise Activity construct and Implemented Activity Behaviour are defined by the AID language [1].

1.4.2	Ending Status of an Implemented Enterprise Activity

Any Enterprise Activity has by definition a special variable attached to it and known by the supporting environment having to control its execution (i.e. services of the Business Entity of the CIMOSA Integrating Infrastructure). This variable is called the Ending Status and always noted Ending_Status in Activity Behaviour [1]. This variable is used by the rules of the Process Behaviour of the processes employing the Enterprise Activity (via the built-in function ES (F) returning the value of the Ending Status of activity F. Initialisation of this variable can be made either

-	in the Implemented Enterprise Activity itself using an assignment statement (e.g. Ending_Status := 'value1')

-	in the post-conditions of Activity Behaviour

-	or by the services of the Integrating Infrastructure when the value is forced in the case of activity execution failure

Thus this variable does not have to be declared in the Implemented Enterprise Activity and can be used freely in the code of the Activity Behaviour.

1.4.3	Synchronisation of and Communication Among Implemented Enterprise Activities

Enterprise Activities of a same Domain or of different Domains of an enterprise are allowed to communicate by exchanging messages and events for synchronisation. For activity occurrences involved in the same Domain Process or Business Process occurrence there is no identification problem as well as for Enterprise Activity of cardinality 1 (for which there is at most one occurrence at any time). In all other cases, a message sent to an Enterprise Activity instance will be sent to the last occurrence created for this activity class.

The language used for Activity Behaviour allows the use of the following special functions defined as Functional Operations and which can be used as statements in the code of an Activity Behaviour:

1) 	Event Generation: "CreateEvent" "(" <ev-name> ")"

where <ev-name> is the identifier of a CIMOSA Event.

This function raises an Event which is sent to the outside. An Object View (the identification and contents of which need to de previously defined) can be attached to it. It is executed by the Business Services of the CIMOSA IIS identified by BS.

2) 	Send Synchronisation Messages: "Send" "(" <EA-name> "," <message-name> ")"

where <EA-name> is the identifier of the Enterprise Activity to which a synchronisation message identified by <message-name> needs to be sent.

3) 	Receive Synchronisation Messages: "Receive" "(" <EA-name> "," <message-name> ")"

where <EA-name> is the identifier of the Enterprise Activity from which a synchronisation message identified by <message-name> is expected.

It can easily be seen that using these functions in the appropriate way, one can make:

-	two or more Enterprise Activities cooperate with one another

-	two or more Enterprise Activities be synchronised together (using a producer/consumer policy with acknowledgement)

-	two or more Enterprise Activities work in a asynchronous mode (no acknowledgement message)

The message passing mechanism allows the communication between concurrent or co-operating Enterprise Activities and furthermore allows internal synchronisation of their processing. Furthermore, Enterprise Activities can also be synchronised by means of their Function Input when an Enterprise Activity has to wait for input information sent by another one.

Important Remark: Therefore CIMOSA provides two synchronisation mechanisms for enterprise tasks which occur in the real-world:

(1) 	global synchronisation (or deterministic synchronisation) which will be under the control of the execution environment because it is described in the logic of Behavioural Rules of processes (for instance, activity 1 must start before activity 2), and

(2) 	operational synchronisation (or non-deterministic synchronisation) which is managed according to real-world event and object occurrences appearing at run-time (for instance, a part loading robot is shared by two work centres being involved in two separate manufacturing processes requires hand-shaking and message exchange).

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Implemented Enterprise Activity instances of all types are described by the following template:

IMPLEMENTED ENTERPRISE ACTIVITY (*)

Type:	[relevant category - select from list <name>; inherited from RDM/DSM]
Identifier: Name: Design Authority: Operation Responsibility: Operation Authority:	[EA-<Unique Identifier>; RDM/DSM] [name of Enterprise Activity instance in the form: <adjective> <noun>   <adjective>: qualifying the Enterprise Activity instance <noun>: related to the scope of the Enterprise Activity;  RDM/DSM] [<identifier> / <name> of Implemented Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance. By default, inherited from RDM/DSM] [<identifier> / <name> of Implemented Organisation Unit and/or Organisation Cell having responsibility on this instance, inherited from DSM] [<identifier> / <name> of Implemented Organisation Unit and/or Organisation Cell having authority for operation of this instance, inherited from DSM]
Body
Interupt ability: A. Descriptional Properties:  OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION:  CAPABILITIES:  INPUT    FUNCTION INPUT:    CONTROL INPUT:    RESOURCE INPUT: OUTPUT    FUNCTION OUTPUT:    CONTROL OUTPUT:    RESOURCE OUTPUT: ENDING STATUSES: ACTIVITY BEHAVIOUR: EXCEPTION HANDLING: AVERAGE DURATION: MINIMUM DURATION: MAX. ACTIVITY DURATION: INPUT PORTS: INPUT CHANNELS: OUTPUT CHANNELS: B. Relational Properties: WHERE USED: COMPRISES:	['Yes' or 'No'; new entry (**)] [non-empty list of <identifier> / <name> of objectives which must be fulfilled by the Enterprise Activity instance] ['NIL' or list of <identifier> / <name> of constraints applicable to this Enterprise Activity instance] ['NIL' or list of <identifier> / <name> of Declarative Rule instances applicable to this Enterprise Activity instance] [textual description of the tasks performed by this Enterprise Activity; optional] ['NIL' or <identifier> / <name> of Capability Set defining required capabilities of occurrences of this Enterprise Activity instance. RDM/DSM] [non-empty list of <identifier> / <name> of Implemented Object View instances describing input information processed by the algorithm of the Implemented Enterprise Activity instance. If preceded by "STREAM OF" means that more than one occurrence of the Object View will be received by the activity during its execution; DSM/RDM If followed by "ON PORT" <port-name> means that Object Views are received/sent on the indicated port. new entry] [list of <identifier> / <name> of Implemented Object View instances describing input information providing run-time data used but not modified by occurrences of the Implemented Enterprise Activity instance; DSM/RDM.  If followed by "ON PORT" <port-name> means that Object Views are received on the indicated port. new entry] [non-empty list of <identifier> / <name> of Implemented Resource Units required by occurrences of this Implemented Enterprise Activity instance. DSM] [non-empty list of <identifier> / <name> of Implemented Object View instances describing the outputs produced by occurrences of the Implemented Enterprise Activity instance. If preceded by "STREAM OF" means that more than one occurrence of the Object View will be received by the activity during its execution; DSM/RDM levels If followed by "ON PORT" <port-name> means that Object Views are received/sent on the indicated port. new entry] [list of <identifier> / <name> of Implemented Event instances, occurrences of which can be generated by occurrences of this activity instance; RDM/DSM To be followed by "ON PORT" <port-name> in the case of exogeneous Events new entry] [list of <identifier> / <name> of Implemented Object View instances describing the status of Resource Units after the execution of occurrences of the Implemented Enterprise Activity instance. DSM] [value and description of all possible Ending Status's produced by occurrences of this Enterprise Activity instance; RDM/DSM] [algorithm of the functionality defined; DSM used to derive variable declarations, statements and exception handling  defined using the syntax provided for Activity Behaviour by the AID language]  [local exception handling mechanisms described using the AID syntax; new entry] [average duration of occurrences of this Enterprise Activity instance; DSM] [minimum duration of occurrences of this Enterprise Activity instance; DSM] [maximum duration of occurrences of this Enterprise Activity instance; DSM] [(possible empty) list of <identifier> / <name> of ports where occurrences of object view and event instance can be received/sent. new entry] [list of channels used for input messages; DSM] [list of channels used for output messages; DSM] [list of <identifier> / <name> of Implemented Domain Process and/or Implemented Business Process employing this Implemented Enterprise Activity. RDM/DSM] [list of Functional Operations employed by this Implemented Enterprise Activity; DSM]
Important remark: A Function Input or Function Output is usually defined as a set of Object Views (the cardinality of which can be 1). In some cases, this is no more a fixed set but a stream of Object Views flowing in/out the activity. Thus option "STREAM OF" is added to these two entries.

Nota: Description, objectives, constraints and Declarative Rules can be inherited from the Requirements Definition and Design Specification Modelling Levels, but they are not processed in the Enterprise Operation Environment.

2.	Background Section

2.1	Examples

IMPLEMENTED ENTERPRISE ACTIVITY

Type:	Administrative/Accounting
Identifier: Name: Design Authority: Operation Responsibility: Operation Authority:	EA-21 'Validate Customer' OU-01 'J.P Smith', OC-004 'Accounting' OC-004 'Accounting' OC-004 'Accounting'
Body
Interupt ability: A. Descriptional Properties:  OBJECTIVES: CONSTRAINTS: DECLARATIVE RULES: FUNCTION DESCRIPTION:  REQUIRED CAPABILITIES: INPUT    FUNCTION INPUT:    CONTROL INPUT:    RESOURCE INPUT: OUTPUT    FUNCTION OUTPUT:    CONTROL OUTPUT:    RESOURCE OUTPUT: ACTIVITY BEHAVIOUR: { EXCEPTION HANDLING: ENDING STATUS: AVERAGE DURATION: MINIMUM DURATION: MAX. ACTIVITY DURATION: INPUT PORTS: INPUT CHANNELS: OUTPUT CHANNELS: B. Relational Properties: WHERE USED: COMPRISES:	O/C-04 'Customer Acceptance' O/C-13 'Credit Limit' DR-1 'Customer Rejection Rule' This enterprise activity is used to check if a customer passing orders is a validate customer in the sense he should not have his credit limit over $ 5000. CS-11 'Validating Customer Capabilities' OV-003 'Processable Orders' ON-PORT 'Administrator Terminal' OV-004 'Product Info OV-005 'Customer Info'  FE-04 'Administrator' OV-006 'New Customer Info' OV-007 'Order' OV-008 'Product Request' OV-009 'Invalid Customer'  NIL  NIL DECLARE Customer_status: integer; Order: Order; Customer: Customer PRE-CONDITIONS:  Not-empty (Processable_Orders);  Not-empty (Customer_Info) BEGIN (* Validate Customer *) SD.Open (Processable_Orders); FOREACH Order IN Processable_Orders DO SD.Select (Customer_Info, Order, Customer); PMG1.Check_Customer_Credit (Customer,  Customer_status); IF Customer_status = OK THEN (* Valid customer *) PMG2.Create_New_Customer  (New_Customer_Info, Customer); PMG3.Collect_All_Orders (Customer, Orders); SD.Write (Orders); ELSE (* Invalid customer *) %.Display ("Customer status: ",Customer_status); %.Write ("Invalid Customer: ", Customer); END Ending_Status := "Validation Completed" END (* Validate Customer *); POST-CONDITIONS: Dispose (Customer_status, Order, Customer)} Time Out = 30 Minutes: Ending Status: = 'Incomplete Validation' Validation Completed: normal termination Incomplete Validation: abnormal termination 01:30 00:30 02:00 P1 (*Administrator Terminal*) NIL NIL Specified Domain Process and Specified Business Process: tbd list of Functional Operations see below
2.2	Document References (none)

2.3	Open Issues (none)

(*)	Part of Header and Body inherited from RDM/DSM Level

(**)	Body additional entries at IDM Level

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Implemented Activity Behaviour
CIMOSA Technical Baseline

Implemented Activity Behaviour

B13-2410. Version: 0.2; Last Update: 94.02.02

1.	Technical Section

1.1	Purpose and Scope

Defines a language to formally describe the functionality of Implemented Enterprise Activities.

1.2	Terms and Definitions

(1)	Implemented Activity Behaviour: defines the internal behaviour (or flow of control) of Implemented Enterprise Activities of the Implementation Description Model. It is based on a formal language which specifies how to perform the functionality of an Implemented Enterprise Activity in terms of an algorithm using Implemented Functional Operations.

1.3	Abbreviations and Acronyms

AID: 	AMICE Implementation Description language

1.4	Description

1.4.1	Generalities

Implemented Activity Behaviour of an Implemented Enterprise Activity is based on a procedural language which describes how to control the execution of Functional Operations to perform a piece of functionality in the Implementation Description Model. The supporting language is called AID [1].

1.4.2	Activity Behaviour Description

Implemented Activity Behaviour is defined in AID by the following syntax in Backus-Naur form:

<Activity-Behaviour> ::= "{" <Declarations> <Preconditions> <Body> <Postconditions> "}"

<Declarations> ::= "DECLARE" <constants> <types> <variables>

<constants> :: = "CONST" <const-def> | NIL

<const-def> ::= <const> <const-def> | NIL

<const> ::= <cidentifier> "=" <c-value> ";"

<cidentifier> ::= identifier (Must be the identifier of a constant.)

<c-value> ::= <numeric-value> | <string-value>

<numeric-value> ::= <sign> <number> | <number>

<sign> ::= "+" | "-"

<number> ::= <digit> | <digit> <number>

<digit> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

<string-value> ::= "'" <s-value> "'"

<s-value> ::= <digit> <letters> | <letter> <letters>

<letters> ::= <letter> <letters> | <digit> <letters> | <symbol> <letters> | NIL

<letter> ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" |

      "T" | "U" | "V" | "X " | "Y" | "Z" | "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |

      "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"

<symbol> ::= "-" | "+" | "*" | "=" | "_" | "!" | "#" | "$" | "%" | "&" | "(" | ")" | "," | ";" | ":" | "." | "?" | "/" | "\" | "|" | "<" |

      ">" | "@" | "'" | "[" | "]" | "{" | "}" | "^" | "~" | """ | blank

<types> ::= "TYPES" <type-def-list> | NIL

<type-def-list> ::= <type-def> <type-def-list> | NIL

<type-def> ::= <type-id> "=" <type-cat> ";"

<type-id> ::= <tidentifier> | <tidentifier> "," <next-tidentifier>

<tidentifier> ::= identifier (Must be the identifier of a type.)

<type-cat> ::= <built-in-types> | <array> | <record> | <enumerated> | <constructed-types>

<built-in-types> ::= "INTEGER" | "REAL" | "BOOLEAN" | "CHAR" | "DATE" | "TIME" | "EXTTIME" |

      "MONEY" | <string> | "FOstatus" | <file>

<file> ::= "FILE" "(" <number> ")" This type allows a file to be considered as a data item to be handled with FTAM services of the Information Entity. Different types of formatted files can be used according to the value of <number> where:

0 is used for ASCII files

1 is used for binary files

5 is used for IGES files

6 is used for STEP files

10 is used for CADAM files (Other codes need to be defined.)

DATE has the format: yyyy:mm:dd or yy:mm:dd where "yyyy" means year as a 4-digit number,

"yy" means year as a 2-digit number, "mm" means month as a 1 or 2-digit number and "dd" means

day as a 1 or 2-digit number.

TIME has the format: hh:mn:ss where "hh" means hour as a 1 or 2-digit number, "mn" means

minute as a 1 or 2-digit number (max. is 60) and "ss" means second as a 1 or 2-digit number (max.

is 60).

EXTTIME represents extended time, i.e. date and time.

MONEY represents amount of money (decimal part reduced to 2 digits).

FOstatus is an integer type reserved for Functional Operation termination status's (must be the

last argument in the parameter list of Functional Operations if used). 0 means successful termination,

 strictly positive values means successful termination under special conditions (defined by the user),

 and 	strictly  negative values mean unsuccessful termination under special conditions defined by

the user.

<string> ::= "STRING" "[" <length> "]"

<length> ::= <number> | <cidentifier>

<array> ::= same as in standard Pascal [2]

<record> ::= same as in standard Pascal

<enumerated> ::= same as in standard Pascal

<constructed-types> ::= same as in standard Pascal

<variables> ::= "VAR" <var-list> | NIL (Used to declare local variables, including Implemented External

     Schemata.)

<var-list> ::= <var> | <var> ";" <var-list> | NIL

<var> ::= <var-names> ":" <type-name>

<var-names> ::= <var-name> | <var-name> "," <var-names>

<var-name> ::= identifier (Must be the name of a variable.)

<type-name> ::= <tidentifier> | <esidentifier> (Must be a type identifier or an Implemented External

     Schema identifier.)

<Preconditions> ::= "PRE-CONDITIONS" <Predicate-List> | NIL

<Postconditions> ::= "POST-CONDITIONS" <Predicate-List> | NIL

<Predicate-List> ::= <Predicate> | <Predicate> ";" <Predicate-List>

<Predicate> ::= <predicate-name> | <predicate-name> "(" <arg-list> ")"

<predicate-name> ::= "Not_empty" | "Lock" | "Unlock" | <others>

<others> ::= to be defined

<Body> ::= "BEGIN" <Instructions> "END"

<Instructions> ::= <Instruction> | <Instruction> ";" <Instructions> | NIL

<Instruction> ::= <assignment> | <seqs> | <conds> | <case> | <while> | <until> | <for> | <foreach> | <parallel> | <FO-call>

Instructions are built using the usual control structures used in standard Pascal with the addition of parallel execution statement. FO-call refers to Functional Operation execution.

1.4.3	Types of Control Structures

The types of control structures which can be used to specify Activity Behaviour are:

1) 	Assignment: <assignment> ::= <var-name> ":=" <value>

2) 	Sequential Control: <seqs> ::= <statement> | <statement> ";" <seqs>

3) 	Conditional Control: <conds> ::= "if" <Boolean-expression> "then" <statements> "end" | "if" <Boolean-expression> "then" <statements> "else" <statements>

4) 	Selective Control: <case> ::= "case" <expression> "of"

v1: <statements> ";"

v2: <statements> ";";

...

vn: <statements>

"else" <statements> "end"

where <expression> may have its value among values v1, v2, ..., vn

5) 	Iterative Controls: <while> ::= "while" <Boolean-expression> "do" <statements> "end"

<until> ::= "do" <statements> "until" <Boolean-expression> "end"

6) 	Iterative Control conditioned by a set of values: <foreach> ::= "foreach" <variable> "in" <set> ["where" <Boolean-expression>] "do" <statements> "end"

where <variable> is the name of a parameter and <set> is a set of values which, for instance, it can be provided by an External Schema. The "where" clause is optional.

This control structure is used whenever it is required to execute a sequence of instructions (<statements>) for each value of a parameter (<variable>) in the set (<set>) verifying the Boolean expression.

7) 	Iterative Control conditioned by an interval: <for> ::= "for" <control-variable> ":=" <initial-value> "to" <final-value> ["by" <step>] "do" <statements> "end"

where <control-variable> is a local parameter of the Enterprise Activity, the scalar values of which vary from <initial-value> to <final-value> by step <step>. The "by" <step> clause is optional; default value of <step> is 1.

This control structure is used to repeat a processing for each value of an array structure.

8) 	Control Structure for Parallel Execution: <parallel> ::= "cobegin" <statement1> "//" <statement2> "//" ...<statementn> "coend"

This control structure allows parallel or concurrent execution of (possibly compound) statements with a rendezvous at the end.

9) 	Statement Definition: All <statements> in the previous control structures are defined by:

<statements> ::= <statement> | <statement> ";" <statements>

<statement> ::= <FO-call> | <Pascal-statement>

FO-call are calls to Functional Operations of an Functional Entity. Other statements are defined by their syntax in standard Pascal.

<FO-call> ::= <FE-name> "." <FO-name> "(" <argument-list> ")"

<FE-name> ::= identifier (Must be the identifier of a Functional Entity.)

FO-name must be the identifier of a Functional Operation of this Functional Entity.

<Boolean-expression> are Boolean expressions involving Boolean terms and arithmetic expressions connected by Boolean operators (AND, OR, NOT).

Comments are allowed in the statements provided that they are enclosed by "(*" and "*)". Comments cannot be nested. Indentation is recommended.

1.4.4	Enterprise Activity Ending Status

Any Enterprise Activity has by definition a special variable attached to it and known by the supporting environment having to process the language. It is called Ending_Status. This variable is used in the Process Behaviour of the processes employing the Enterprise Activity. Initialisation of this variable can be made in the Implemented Enterprise Activity itself within one of the statements used in control structures of the language. Thus this variable does not have to be declared in the Implemented Enterprise Activity and can be used freely in the pseudo-code of the algorithm.

1.4.5	Functional Operation Declaration

Definition: Each Implemented Functional Operation is used in Activity Behaviour as follows:

<FO-def> ::= <FO-Name> <argument-list>

<FO-Name> ::= identifier (Must be the name of a Functional Operation of the Implemented Functional

Entity being described.)

<argument-list> ::= NIL | "(" <argu-list> ")"

<argu-list> ::= <input-arg> | <output-arg> | <input-output-arg> | <input-arg> "," <output-arg> | <input-arg> "," <output-arg> "," <input-output-arg> | <output-arg> "," <input-output-arg>

- <argument-list> is a sequence of names of input/output variables (parameters or External Schemas)

separated by comma which pass and receive information required or returned by the Functional

Operation. One the output parameter can be the ending status.

<input-arg> ::= "IN" <arg-list>

<output-arg> ::= "OUT" <arg-list>

<input-output-arg> ::= "INOUT" <arg-list>

Input parameters are read only (their value is not changed), output parameters have an

undefined value when the activity starts and have a defined value when the activity normally

finishes, input/output parameters (INOUT) have a defined value when the activity starts and

can have a different value when the activity stops.

<arg-list> ::= <arg> | <arg> "," <arg-list>

<arg> ::= <formal-parameter> ":" <arg-type>

<formal-parameter> ::= identifier (Must be an identifier of a formal parameter)

<arg-type> ::= <type> | <esch-name>

This mechanism is very similar to the activation of a method of an object by a message as used in the object-oriented approach.

Note 1: The list of arguments can be empty.

Note 2: Implemented Functional Operations can only be used by the algorithm of the Activity Behaviour of Implemented Enterprise Activities.

Each Implemented Functional Entity can perform a finite set of Implemented Functional Operations as indicated in their set of commands. The structure of these commands (or callable functions) fix the format (i.e. the list of arguments) of Implemented Functional Operations. Some of the arguments can indicate the status of the result of the execution of the Functional Operation.

1.4.6	Synchronisation of and Communication Among Implemented Enterprise Activities

Enterprise Activities of a same Domain or of different Domains of an enterprise are allowed to communicate by exchanging messages and events for synchronisation. For activity occurrences involved in the same Domain Process or Business Process occurrence there is no identification problem as well as for Enterprise Activity of cardinality 1 (for which there is at most one occurrence at any time). In all other cases, a message sent to an Enterprise Activity instance will be sent to the last occurrence created for this activity class.

The language used for Activity Behaviour allows the use of the following special functions defined as Functional Operations and which can be used as statements in the code of an Activity Behaviour:

1) 	Event Generation: "CreateEvent" "(" <ev-name> ")"

where <ev-name> is the identifier of a CIMOSA Event.

This function raises an Event which is sent to the outside. An Object View (the identification and contents of which need to de previously defined) can be attached to it. It is executed by the Business Services of the CIMOSA IIS identified by BS.

2) Send Synchronisation Messages: "Send" "(" <EA-name> "," <message-name> ")"

where <EA-name> is the identifier of the Enterprise Activity to which a synchronisation message identified by <message-name> needs to be sent.

3) Receive Synchronisation Messages: "Receive" "(" <EA-name> "," <message-name> ")"

where <EA-name> is the identifier of the Enterprise Activity from which a synchronisation message identified by <message-name> is expected.

It can easily be seen that using these functions in the appropriate way, one can make:

-	two or more Enterprise Activities cooperate with one another

-	two or more Enterprise Activities be synchronised together (using a producer/consumer policy with acknowledgement)

-	two or more Enterprise Activities work in a asynchronous mode (no acknowledgement message)

The message passing mechanism allows the communication between concurrent or co-operating Enterprise Activities and furthermore allows internal synchronisation of their processing. Furthermore, Enterprise Activities can also be synchronised by means of their Function Input when an Enterprise Activity has to wait for input information sent by another one.

Important Remark: Therefore CIMOSA provides two synchronisation mechanisms for enterprise tasks which occur in the real-world:

(1) 	global synchronisation (or deterministic synchronisation) which will be under the control of the execution environment because it is described in the logic of Procedural Rules of processes (for instance, activity 1 must start before activity 2), and

(2) 	operational synchronisation (or non-deterministic synchronisation) which is managed according to real-world event and object occurrences appearing at run-time (for instance, a part loading robot is shared by two work centres being involved in two separate manufacturing processes requires hand-shaking and message exchange).

1.4.7	Built-in Functional Operations

These Functional Operations are known by the CIMOSA environment and will be executed by services of the Integrating Infrastructure.

Reading input: To get the information contained in an Object View identified by <ov-name> on a Function Input of an Enterprise Activity identified by <ea-name>, one can write:

<ea-name> "?" <ov-name>

If the Object View has to go through a port, this is indicated by the Function Output description.

Sending output: To send an Object View identified by <ov-name> on the Function Output of the Enterprise Activity identified by <ea-name>, one can write :

<ea-name> "!" <ov-name>

If the Object View has to go through a port, this is indicated by the Function Output description.

Lock Channel: To lock a channel identified by <ch-name> for exclusive use, one can write:

"Lock" "(" <ch-name> ")"

Unlock Channel: Similarly, to unlock a locked channel identified by <ch-name>, one can write:

"Unlock" "(" <ch-name> ")"

1.4.8	Final Remarks

The language makes use of pre-conditions. This is a way to implement some of the Declarative Rules defined at the Requirements Definition Modelling Level and validated at the Design Specification Modelling Level and which have to be taken into account during execution. Remember that in CIMOSA Release 1.0 no mechanism is provided by the Integrating Infrastructure to directly handle Declarative Rules.

2.	Background Section

2.1	Examples (tbd)

2.2	Document References (none)

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Implemented Event
CIMOSA Technical Baseline

Implemented Event

B13-2500. Version: 0.3; Last Update: 96.03.01

1.	Technical Section

1.1	Purpose and Scope

Defines the implementation description of Events of an enterprise.

1.2	Terms and Definitions (none)

(1)	Implemented Event:

(a)	is a fact specifying a request to do something or a real-world happening occurring at a given instant in time from a given source and indicating a change in the state of the enterprise.

(b)	is a modelling construct inherited from the Requirements Definition Model and the Design Specification Model. It can carry information (defined as an Implemented Object View). It is used to trigger the execution of one or more Implemented Domain Processes of the Implementation Description Model by initiating the processing of the associated Implemented Process Behaviour.

1.3	Abbreviations and Acronyms

DSM: 	Design Specification Model

PIDM: 	Particular Implementation Description Model

DP:	Domain Process

EV:	Event

OC:	Organisation Cell

RDM: 	Requirements Definition Mode

OU:	Organisation Unit

OV:	Object View

1.4	Description

This construct provides the description of Events at the Implementation Description Modelling Level, and especially indicates on which port exogeneous occurrences of the Event instance can be received. The construct has basically the same structure than at previous modelling levels and inherits properties for the Design Specification Modelling Level.

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects. Implemented Event instances of all types are described by the following template:

IMPLEMENTED EVENT (*)

Type:	[relevant category - select from list <name>; inherited from RDM/DSM]
Identifier: Name: Design Authority: Operation Responsibility: Operation Authority:	[EV-<unique identifier>; RDM/DSM] [name of the Specified Event instance in the form: <adjective > <noun> <noun>: relates to the object causing the Event  <adjective>: qualifying attribute; RDM/DSM]  [<identifier> / <name> of Implemented Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance. RDM/DSM] [<identifier> / <name> of Implemented Organisation Unit and/or Organisation Cell with responsibility on this instance, DSM] [<identifier> / <name> of Implemented Organisation Unit and/or Organisation Cell with authority for operation of this instance; DSM]
Body
A. Descriptional Properties:  OBJECT VIEW: TIMESTAMP: PRIORITY: INPUT PORTS: B. Relational Properties: GENERATED BY: TRIGGERS	[<identifier> / <name> of Implemented Object View instance defining information attached to occurrences of the Event instance; RDM/DSM] yy.mm.dd:hh.mm.ss:mmm (type defining date and time to be provided at occurrence creation time; DSM) Timestamp has a fixed value which is a type for date and time (and cannot be changed because it is known by the system). [an integer between 1 and 6 included. DSM] [(possible empty) list of <identifier> / <name> of ports where occurrences of this event instance can be received. Empty if the Event is endogeneous; new entry (**)] [non-empty list of <identifier> / <name> of Implemented Domain or Implemented Enterprise Activity, occurrences of which can generate an occurrence of this Event instance. RDM/DSM] [list of <identifier> / <name> of Implemented Domain Process, Implemented Business Process, Implemented Enterprise Activity and Implemented Resource instances, occurrences of which can be triggered by occurrences of this Event instance. RDM/DSM]
2.	Background Section

2.1	Examples

EVENT

Header
Type: Identifier: Name: Design Authority: Operation Responsibility: Operation Authority:	Management order/Change request EV-04 'PCB Change Request' OU-01: 'M. Synders', OC-002 'Product Engineering' OC-002 'Product Engineering' OC-002 'Product Engineering'
Body
A. Descriptional Properties:  DESCRIPTION: RELATED OBJECT VIEW: TIMESTAMP: PRIORITY: INPUT PORTS: B. Relational Properties: GENERATED BY: TRIGGERS	Modification of specification at request of customer. This leads to a Change Request. OV-010 'PCB-data Date of Creation 6 (an integer between 1 and 6) P1 (*Administrator Terminal*) DP-04 'Prototypes Manufacturing' DP-05 'PCB Design'
2.2	Document References

2.3	Open Issues (none)

(*)	Part of Header and Body inherited from RDM/DSM Level

(**)	Body additional entries at IDM Level

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


 CIMOSA Outline

 Table of Contents

 Business Oriented Modelling

 IDM Level - Function View

 Function View, Implementation Description Modelling Level

 Generic Building Blocks of the Function View, Implementation Description Modelling Level

 Implemented Domain

 Implemented Domain Process

 Implemented Process Behaviour

 Implemented Business Process

 Implemented Enterprise Activity

 Implemented Activity Behaviour

 Implemented Event

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Information View, Implementation Description Modelling Level
CIMOSA Technical Baseline

Information View,

Implementation Description Modelling Level

B23-1000. Version: 2.2; Last Update: 94.02.02

1.	Technical Section

1.1	Purpose and Scope

Provides the Information View constructs at the Implementation Description Modelling Level and their relationships as implemented through information technology.

1.2	Terms and Definitions

(1)	Information View, Implementation Description Modelling Level:

(a)	is the Information View of the Implementation Description Modelling Level as defined in the European Pre-norm (ENV 40 003).

(b)	consists-of:

-	non-empty-set-of Generic Building Blocks for implementation description in the Information View and

-	set-of Building Block Types for implementation description in the Information View and

-	set-of Partial Implementation Description Models for the Information View and

-	one Particular Implementation Description Model for the Information View.

1.3	Abbreviations and Acronyms

CEN/CENELEC: 	Comité Européen de Normalisation/-"- Electrotechnique

ENV:	European Norm

AID: 	AMICE Implementat. Description language

1.4	Description

At the Implementation Description Modelling Level the Information View describes a unified view of the data formats and storage structures of business data and information. Thus it provides constructs to describe the physical data models of the Internal Schema and implementation description of External Schemata, Integrity Constraints and defined at the Design Specification Modelling Level. Database Transactions implemented as Functional Operations of Implemented Enterprise Activities. The CIMOSA Information View is described by Information View Modelling Paradigms.

The Information View of the Implementation Description Modelling Level is made of three sub-parts:

1.	The Generic Implementation Description Building Blocks which form a structured catalogue of all Generic Building Blocks and Building Block Types of the Information View used for implementation description;

2.	The Partial Implementation Description Models which make up a structured catalogue of classified (partially) instantiated aggregations of Information View generic constructs used to instantiate Particular Implementation Description Models;

3.	The Particular Implementation Description Model contains which all implementation descriptions for the Information View of one individual enterprise.

At the Implementation Description Modelling Level, the Conceptual Schema and its External Schemata are optimised and expressed in terms of an implementation language to produce the Internal Schema of the Information System of the Enterprise. So far the SQL language is the basic data language used at the Implementation Description Modelling Level of the Information View. However, other data languages may also be used for relational, network, hierarchical or object-oriented structures.  Syntax and semantics of Information View Constructs at the Implementation Description Modelling Level are defined in the AID (AMICE Implementation Description) language ([2]).

2.	Background Section

2.1	Examples (not applicable)

2.2	Document References

1.	ENV 40 003: Computer Integrated Manufacturing. Systems Architecture. Framework for Enterprise Modelling. CEN/CENELEC, 1990.

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Generic Building Blocks of the Information View, Implementation Description Modelling Level
CIMOSA Technical Baseline

Generic Building Blocks of the Information View,

Implementation Description Modelling Level

B23-2000. Version: 3.3; Last Update: 96.03.01

1.	Technical Section

1.1	Purpose and Scope

Provides the list of Generic Building Blocks of the Information View to be used in the CIMOSA Reference Architecture and the Particular Architecture for the specification of an Information System of an enterprise model implementable in information technology.

1.2	Terms and Definitions

(1)	Generic Building Blocks of the Information View, Implementation Description Modelling Level:

(a)	are used to build Partial Implementation Description Models and Particular Implementation Description Models.

(b)	set of Generic Building Blocks and Building Block Types of Business and IT oriented modelling constructs of the Information View. The set of Generic Building Blocks consists-of:

Business Modelling

-	 Implemented Object View - OV

IT oriented Modelling

- 	Logical Data Model

- 	Physical Data Model

- 	Implemented External Schema

- 	Internal Schema

1.3	Abbreviations and Acronyms

AID: 	AMICE Implementat. Description language

ERA:	Entity-Relationship-Attribute approach

IT:  	Information Technology

SQL:	Structured Query Language

CEN: 	Comité Européen de Normalisation

ENV:	European pre-Norm

1.4	Description

The CIMOSA Generic Building Blocks of the Information View at the Implementation Description Modelling Level are used to build up the CIMOSA Information View Modelling Paradigm at this Modelling Level. At the implementation level the Information System of an Enterprise is packaged into an Internal Schema which describes how the information is structured, how to access it, who has the right to access what and what are the constraints which apply to it (Integrity Constraints). The Internal Schema provides an IT view of the Implemented Object Views (or Business User's view).

Figure B23-2000/1: Generic Building Blocks and their Relations of the Information View at the Implementation Description Modelling Level

First a Logical Data Model is produced, i.e. a direct (possibly automatic) translation of the Conceptual Schema as an ERA model into a classical, neutral, data model (relational form). This model is then "optimised" to meet the implementation requirements in the form of a Physical Data Model, which is the information structure part of the Internal Schema expressed in terms of the implementation language form used by CIMOSA (i.e. a SQL-based language). The Internal Schema will be completed with further implementation descriptions such as data distribution and access rights for system installation during the Release Process of the System Life Cycle..

Implemented External Schemata provide an implementation description of the Object Views defined by the users. These are limited "views" of the total information structure contained in the Internal Schema. Generic Building Blocks used at this modelling Level and their relationships are shown by Figure B23-2000/1.

The syntax and semantics of constructs used in the Information View, Implementation Description Modelling Level, are given in the AID (AMICE Implementation Description) language [1].

2.	Background Section

2.1	Examples (not applicable

2.2	Document References

1.	CEN/CENELEC 1990, Computer Integrated Manufacturing Systems Architecture Framework for Enterprise Modelling, ENV 40 003

2.	CEN/TC310/WG1 1995, Advanced Manufacturing Technology - Systems Architecture Constructs for Enterprise Modelling, ENV 12 204

2.3	Open Issues (none)

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Implemented Object View
CIMOSA Technical Baseline

Implemented Object View

B23-2300. Version: 0.4; Last Update: 96.03.01

1.	Technical Section

1.1	Purpose and Scope

Describes the implementation of an Object View.

1.2	Terms and Definitions

(1)	Implemented Object View:

(a)	is the description of the implementation of an Object View.

(b)	is a modelling construct inherited from the Requirements Definition Model and the Design Specification Model, providing the description of one aspect of one or more Enterprise Objects. It therefore describes a subset of properties owned by one or more Enterprise Objects from a given stand-point. It is made of Information Elements and/or other Implemented Object Views.

1.3	Abbreviations and Acronyms

AID: 	AMICE Implementation. Description language

RDM: 	Requirements Definition Model

OC:	Organisation Cell

OU:	Organisation Unit

DSM: 	Design Specification Model

IDM: 	Implementation Description Model

OV:	Object View

1.4	Description

1.4.1	Generalities

Implemented Object View is a construct used to describe the implementation of Object Views as defined and specified at the Requirements Definition and Design Specification Modelling Levels. From a Business User's point of view, Implemented Object Views are objects to be manipulated. From an Information Technology point of view, Implemented Object Views are complex data structures as global variables in the CIM-OSA Model.

An Implemented Object View inherits most of the properties of a Specified Object View as defined at the Design Specification Modelling (DSM) Level and adds additional features. Especially it indicates on which port(s) an occurrence of the Object View can be received/sent if it comes from/goes to the outside world. However, an Object View may have no input/output port if it is only used within the Domain or internally to the CIMOSA model. (See Implemented Domain item).

The format of the Object View (i.e. presentation or display of its Information Elements listed in the PROPERTIES entry) to be used by the Presentation Services is decided during installation of the Release Process of the CIMOSA System Life Cycle. In the case of information Object Views, a default format (using names of attributes used in the related Implemented External Schemata followed by their value) can be used. Otherwise, a special formatting language (to be defined) needs to be used to use the names of Information Elements and present the information in a structured way on the display medium. Such a language must allow to define headers, sub-headers, add dates, comments, calculated values, and so on.

CARDINALITY entry indicates the maximum number of occurrences allowed for this Implemented Object View instance. If this number is unknown or unbounded, the symbol "#" is used.

PERSISTENCE entry, "permanent" storage means that the information has to be stored and is handled by the services of the Information Entity. "temporary" means that the information is volatile and need to be stored in a shared memory which has to be used by at least two Enterprise Activities (output of one used as input of the other one).

Input/output ports indicate the connection points of the physical system where occurrences of this instance can be received or sent.

IMPLEMENTED EXTERNAL SCHEMATA entry indicates External Schemata (or SQL views) to be executed to obtain values for the Information Elements (i.e. properties) of the Object View.

IMPLEMENTATION entry indicates which Implemented External Schemata (SQL views) have to be executed in order to instantiate the Information Elements (i.e. properties) of the occurrences of the Object View. Input parameters may be necessary for SQL SELECT statements used by SQL views of External Schemata. The exact syntax of this entry is defined in the AID language [1].

1.4.2	General Constraints

-	The instantiation of Implemented Object Views at the Partial and Particular Implementation Description  Modelling Level is constrained by the defined Implemented Object View Instantiation Rules (described in the D-series Items).

-	All Implemented Object Views defined at the Implementation Description Modelling Level will be implemented in terms of Implemented External Schemata.

1.5	Description Template

The template shows the information content of the construct. This information may be provided as input by the user, or generated by a tool. The template is provided to guide current CIMOSA users and architects.

Implemented Object View instances of all types are described by the following template:

IMPLEMENTED OBJECT VIEW (*)

Header
Type: Identifier: Name: Design Authority: Operation Responsibility: Operation Authority:	[relevant category - select from list or inherited from RDM/DSM] [OV-unique number; RDM/DSM] [name of the Object View instance; RDM/DSM] [<identifier> / <name> of Implemented Organisation Unit and/or Organisation Cell with authority to design/maintain this particular instance. RDM/DSM] [<identifier> / <name> of Implemented Organisation Unit and/or Organisation Cell  with responsibility on this instance, DSM] [<identifier> / <name> of Implemented Organisation Unit and/or Organisation Cell  with authority for operation of this instance, DSM]
Body
A. Descriptional Properties:  Description: Nature: PROPERTIES: CONSTRAINTS: CARDINALITY: PERSISTENCE: INPUT/OUTPUT PORTS: IMPLEMENTATION: B. Relational Properties: IMPLEMENTED EXTERNAL SCHEMATA:	[short textual description. , RDM/DSM] ['Physical' or 'Information'. RDM/DSM] [list of Properties of the Implemented Object View instance; RDM/DSM] [list of constraints applicable to properties the Object View instance. The selection clause starts by the reserved word "WHERE" and is made of a conjunctive list of first-order predicates; optional. RDM/DSM] [number indicating the maximum number of occurrences for this instance. If this number is unbounded, the value "#" is used; new entry (**)]  ["permanent" or "temporary"; new entry] [name of input/output ports, if any; new entry] [non-empty list of statement of the form "EXECUTE" <identifier of Implemented External Schema> "GIVING" <names of Information Elements> and separated by ","; new entry] [non-empty list of <identifier> / <name> of Implemented External Schema instances employed by the Object View instance; new entry]
2.	Background Section

2.1	Examples

IMPLEMENTED OBJECT VIEW (*)

Header
Type: Identifier: Name: Design Authority: Operation Responsibility: Operation Authority:	Product Data OV-04 'Product Info' OU-05 'K. Maier', OC-006 'Sales' OC-006 'Sales' OC-006 'Sales'
Body
A. Descriptional Properties:  Description: Nature: PROPERTIES: CONSTRAINTS: CARDINALITY: PERSISTENCE: INPUT/OUTPUT PORTS: IMPLEMENTATION: B. Relational Properties: LEADING OBJECT: RELATED OBJECTS: EXTERNAL SCHEMATA:	Product description from the sales department viewpoint Information Product_id:string[12] Product_Name:string[15] Description:string[30] Type_Code:string[5] Alternate_Code:string[5] ABC_Code:string[3] Leadtime:integer Standard_Cost:money Unit_of_Measure:integer Drawing_Id::string[12] Exist (Product_id); WHERE (Type_Code LIKE "ABC$") AND Leadtime <= 50 EO-02 'End Product' EO-03 'Product History'
2.2	Document References (none)

2.3	Open Issues (none)

(*)	Part of Header and Body inherited from RDM/DSM Level

(**)	Body additional entries at DSM Level

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


IDM Level - Information View
 CIMOSA Outline

 Table of Contents

 Business Oriented Modelling

 IDM Level - Information View

 Information View, Implementation Description Modelling Level

 Generic Building Blocks of the Information View, Implementation Description Modelling Level

 Implemented Object View

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


A
CIMOSA Glossary

Activity Behaviour

Abbreviation: none

Source Document: Part I/B12-24101

defines the internal behaviour (or flow of control) of Specified Enterprise Activities of the Design Specification Model. It specifies how to perform the functionality of an Enterprise Activity in terms of an algorithm making use of Functional Operations.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


B
CIMOSA Glossary

Behavioural Rule

Abbreviation: none

Source Document: Part I/B11-27101

Building Block component which describes the desired action(s) to be taken in the flow of control of a Domain Process or a Business Process.

set of Behavioural Rules defines the flow of control of Domain Process or Business Process by definition of selection criteria for executing a cluster of Business Processes and/or Enterprise Activities.

BP = Business Process

Source Document: Part I/B11-28002

describes pieces of enterprise behaviour at all levels of decomposition of the functional decomposition except the top and bottom levels. It may have a functional part defined, and must have a behaviour part and a structural part. It is employed by one or more Domain Processes and/or Business Processes and it employs one or more Business Processes and/or Enterprise Activities. It is triggered by a parent structure (Domain Process or Business Process).

Building Block Instance

Abbreviation: none

Source Document: Part I/B0-73002 - Building Block Instance

user defined individual of a Generic Building Block or Building Block Type, the characteristic of which (i.e. elements) have been partially (Partial Level) or fully (Particular Level) defined.

Building Block Type

Abbreviation: none

Source Document: Part I/B0-72002 - Building Block Type

specialisation of a Generic Building Block or a more generic Building Block Type;

has the nature of an object Class and therefore is defined by its name, a reference to its parent class, a list of elements (properties defining descriptive characteristics or components) and rules constraining the possible values for each element.

Building Block Occurrence

Abbreviation: none

Source Document: Part I/B0-74002 - Building Block Occurrence

run-time copy of a particular Building Block Instance, as required during execution within the Enterprise Operation Environment

Business Process

Abbreviation: BP

Source Document: Part I/B11-28002

describes pieces of enterprise behaviour at all levels of decomposition of the functional decomposition except the top and bottom levels. It may have a functional part defined, and must have a behaviour part and a structural part. It is employed by one or more Domain Processes and/or Business Processes and it employs one or more Business Processes and/or Enterprise Activities. It is triggered by a parent structure (Domain Process or Business Process).

 (c)  1993 - 1996 CIMOSA Association. All rights reserved.


C
CIMOSA Glossary

Capability

Abbreviation: none

Source Document: Part I/B31-2100

element of the construct Capability Set which is defined by its name and value or a set of enumerated values or a range of values. Capabilities are used to describe: Function related Capabilities, Object related Capabilities, Performance related Capabilities, Operation related Capabilities

Capability Set

Abbreviation: none

Source Document: Part I/B31-21002

Generic Building Block defined as a collection of Capability Elements or Capabilities. It describes the set of Capabilities required by an Enterprise Activity.

CIMOSA Domain

Abbreviation: none

Source Document: Part I/B11-21002

represents a subset of the enterprise (i.e. the universe of discourse) to be analysed and for which a CIMOSA compliant Particular Model will be created (i.e. instantiated);

a construct used to establish the content and the boundary of the part of the enterprise, which is subject to analysis based on a given set of business objectives and constraints. It is made of a set of interacting Domain Processes, Events and Object Views (information objects and physical objects including resources).

CIMOSA Genericity Levels

Abbreviation: none

Source Document: Part I/B0-50003 - CIMOSA Genericity Levels

define along its stepwise instantiation axis three Genericity Levels: the Generic Level, the Partial Level and the Particular Level.

the Generic Level and the Partial Level collectively constitute the set of models in the CIMOSA Reference Architecture.

the Particular Level constitutes the set of models in a CIMOSA Particular Architecture.

CIMOSA Model Creation Processes

Abbreviation: none

Source Document: Part I/D0-10003

set of guidelines used to create the different contents of the Particular Architecture of a given enterprise from Generic Building Blocks and Partial Models of the CIMOSA Reference Architecture;

define the rules to follow in order to move along the three axes of the CIMOSA Architectural Framework to produce the Particular Architecture of an enterprise. They are further subdivided into: the Instantiation Process, the Generation Process and the Derivation Process.

CIMOSA Models

Abbreviation: none

Source Document: Part I/B5-1000

used to describe the different phases of the enterprise life cycle (Requirement Definition, Design Specification and Implementation Description).

are subject to an enterprise engineering process (model development process) which is concerned with both model creation and model maintenance (model update and modification).

contain sets of instances of Generic Building Blocks and Building Block Types structured to present solutions to problem areas in manufacturing enterprises in a process oriented language.

may represent partial (partially instantiated) or particular (fully instantiated) solutions.

CIMOSA Modelling Framework

Abbreviation: none

Source Document: Part I/B0-20003 - CIMOSA Modelling Framework

provides a common structure for semantic unification within enterprise in the form of:

the CIMOSA Reference Architecture, which provides building blocks/constructs for enterprise modelling

the CIMOSA Particular Architecture, created for the particular enterprise using the reference Architecture.

represented by a three-dimensional structure whose orthogonal axes define the CIMOSA Model Creation Processes: Stepwise Instantiation, Stepwise Derivation and Stepwise Generation

applied and maintained through the definition and use of CIMOSA Environments: Enterprise Engineering Environment and Enterprise Operation Environment.

CIMOSA Modelling Levels

Abbreviation: none

Source Document: Part I/B0-40003 - CIMOSA Modelling Levels

define three Modelling Levels: Requirements Definition, Design Specification and Implementation Description;

associated with each Modelling Levels there exist: a defined set of Generic Building Blocks and Building Block Types, Partial Models and a Particular Model

CIMOSA Particular Architecture

Abbreviation: none

Source Document: Part I/B0-22003 - CIMOSA Particular Architecture

defines the architectural solution for a specific manufacturing enterprise in a form derived directly from the CIMOSA Reference Architecture, conditioned by the needs and the requirements of that specific enterprise.

CIMOSA Reference Architecture

Abbreviation: none

Source Document: Part I/B0-21003 - CIMOSA Reference Architecture

definite base from which CIMOSA Particular Architectures may be created. It consists of defined extendible sets of: Generic Building Blocks and Building Block Types defined as object classes, Partial Models and relationships, rules and constraints governing the application of the modelling constructs and Partial Models for specific use.

CIMOSA View

Abbreviation: none

Source Document: Part I/B0-30003 - CIMOSA Views

defines along its Stepwise Generation Axis four views (Function, Information, Resource, Organisation) which allow to focus on specific aspects of integrated enterprise models discarding others.

Construct

Abbreviation: none

Source Document: Part II/B0-2100 - CIMOSA Reference Architecture

general term to cover components of Generic Building Blocks, Generic Building Blocks, Building Block Types, Partial Models, Particular Models as well as their instances.

Control Input

Abbreviation: none

Source Document: Part I/B11-22504

Building Block Component defined as a set of Object Views which are used to direct (i.e. constrain) or pass run-time information on an Enterprise Activity but will not be modified by the functionality of the Enterprise Activity. Control input can also apply to Domain Processes and Business Processes.

Control Output

Abbreviation: none

Source Document: Part I/B11-22604

Building Block Component defined as a (possibly empty) set of Events occurrences of which can be generated by occurrences of an Enterprise Activity.  Control Output can also apply to Domain Processes and Business Processes.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


D
CIMOSA Glossary

Data

Abbreviation: none

Source Document: Part I/B0-1300 - Information System of an Enterprise

Data are made up of two things: a fact (i.e. a value) and a meaning.

Database Transaction (IT oriented Modelling)

Abbreviation: none

Source Document: Part I/B22-24005

used to describe a logical unit of work to be performed on the information storage system, and perceived by the end-users as a single, atomic operation;

works on parts of the Conceptual Schema, called Sub-Schemata, using data from input Sub-Schemata and producing data for output Sub-Schemata under some execution rule, expressed as an execution constraint; describes the dynamics of the data schema of an Information System.

Decision Centre

Abbreviation: none

Source Document: Part I/B0-1200 - Decision System of an Enterprise

functional entity of the enterprise which can make decisions for a given horizon on the basis of information about the enterprise or its environment.

Decision Level

Abbreviation: none

Source Document: Part I/B0-1200 - Decision System of an Enterprise

made of a certain number of Decision Centres and is characterised by its planning horizon and the level of abstraction of its model (in terms of aggregation of data, entities and criteria to be optimised).

Decision System (of a manufacturing Enterprise)

Abbreviation: none

Source Document: Part I/B0-12005 - Decision System of an Enterprise

represents the set of predictive, administrative, planning, control and maintenance functions necessary to perform day-to-day operations of the Physical System.

Declarative Rule

Abbreviation: none

Source Document: Part I/B11-25005

set of objectives and constraints combined with a set of conditions for their applicability (i.e. a Declarative Rule allows objectives and constraints to be combined and applied under conditions) Declarative Rules can be imposed within Domains on Domain Processes and Business Processes and Enterprise Activities.

Derivation Process

Abbreviation: none

Source Document: Part IV/D0-13005

CIMOSA architectural principle which enforces the use of a structured approach during the continuous evolution of Partial or Particular Architecture's of CIM systems from requirements definition down to design specification and then to implementation description.

Design Specification Modelling Level

Abbreviation: none

Source Document: Part I/B0-42005 - Design Specification Modelling Level

specifies how the enterprise operations are to be performed, that is the actions and processes that are to be performed to achieve the enterprise requirements taking time into account.

defines constructs applicable for use at each of the CIMOSA Generic, Partial and Particular Level

Design Specification Models

Abbreviation: DSM

Source Document: Part I/B0-4200 - Design Specification Modelling Level

contain all the functional, information, resource and organisational specifications for an optimised operational enterprise system verifying the business requirements of an enterprise.

express the system specifications using CIMOSA Function, Information, Resource and Organisation Views.

provide both the business user and system designer type representation.

Domain Boundary

Abbreviation: none

Source Document: Part I/B11-2600

defined by a set of Domain Relationships.

Domain Constraint

Abbreviation: none

Source Document: Part I/B11-21206

describe Enterprise constraints imposed on a Domain, expressing conditions restraining the range of possibilities of some enterprise processes or entities within that Domain. They are defined using the Objective/Constraint Generic Building Block.

Domain Objective

Abbreviation: none

Source Document: Part I/B11-21106

defines the business goals and required achievements of a Domain, i.e. measurable and realistic end results desired for the enterprise business; They express capabilities expected from the business environment defined using the Objective/Constraint Generic Building Block.

Domain Process

Abbreviation: DP

Source Document: Part I/B11-27006

triggered by means of at least one Event and nothing else than Events and producing end results (Function Output). It encapsulates a well defined set of enterprise functionalities and behaviour (i.e. Enterprise Activities and Business Process) to realise clearly defined objectives (Domain Objectives) under given constraints (Domain Constraints).

receives input from and/or provides output to other Domain Processes. It is only used by one Domain, i.e. it is not used either by any other Domain or a Business Process, and therefore is at the top of a functional decomposition hierarchy.

Domain Relationship

Abbreviation: none

Source Document: Part I/B11-26006

used to define the interactions between two related Domains.

indicates Events and Object Views which can be exchanged by two Domains, specifying which are going and which are going out of the Domain.

DP=Domain Process

Source Document: Part I/B11-27006

triggered by means of at least one Event and nothing else than Events and producing end results (Function Output). It encapsulates a well defined set of enterprise functionalities and behaviour (i.e. Enterprise Activities and Business Process) to realise clearly defined objectives (Domain Objectives) under given constraints (Domain Constraints).

receives input from and/or provides output to other Domain Processes. It is only used by one Domain, i.e. it is not used either by any other Domain or a Business Process, and therefore is at the top of a functional decomposition hierarchy.

DSM = Design Specification Models

Source Document: Part I/B0-4200 - Design Specification Modelling Level

contains all the functional, information, resource and organisational specifications for an optimised operational enterprise system verifying the business requirements of an enterprise.

express the system specifications using CIMOSA Function, Information, Resource and Organisation Views.

provide both the business user and system designer type representation.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


E
CIMOSA Glossary

EA=Enterprise Activity

Source Document: Part I/B11-22006

describes a piece of functionality in the Function View of a particular enterprise at the Requirements Definition Modelling Level, i.e. "one of the things to be done".

a construct which has a functional part and a structure part defined, but not a behaviour part. It is employed by one or more Domain Processes and/or Business Processes, but does not employ any Business Process or Enterprise Activities. It is characterised by the definition of its inputs and outputs.

Enterprise Activities of a particular enterprise define elementary tasks to be performed in the enterprise which consume inputs to produce outputs and need allocation of time and resources for the full duration of their execution.

Ending Status

Abbreviation: none

Source Document: Part I/B11-22906

of an Enterprise Activity (respectively a Business Process) is a value describing one of possible termination states of an Enterprise Activity (respectively a Business Process), and required for further processing in the Set of Behavioural Rules in which the Enterprise Activity (respectively, this Business Process) is involved.

Enterprise

Abbreviation: none

Source Document: Part I/B0-10007 - Enterprise

set of management, operational and support processes functions, and a set of physical and human resources, all supported by financial resources, executing activities for the purpose of producing goods or services.

Enterprise Activity

Abbreviation: EA

Source Document: Part I/B11-22007

describes a piece of functionality in the Function View of a particular enterprise at the Requirements Definition Modelling Level, i.e. "one of the things to be done".

a construct which has a functional part and a structure part defined, but not a behaviour part. It is employed by one or more Domain Processes and/or Business Processes, but does not employ any Business Process or Enterprise Activities. It is characterised by the definition of its inputs and outputs.

Enterprise Activities of a particular enterprise define elementary tasks to be performed in the enterprise which consume inputs to produce outputs and need allocation of time and resources for the full duration of their execution.

Enterprise Engineering

Abbreviation: none

Source Document: Part IV/D1-0100

application of engineering disciplines to the requirements specification, system design, implementation, release and change/maintenance of Enterprise systems.

Enterprise Object

Abbreviation: none

Source Document: Part I/B21-21007

describes generalised, real or abstract, uniquely identified, entity of the enterprise's Information System (i.e. things which can be conceptualised or thought about as being a whole), and characterised by a unique identity, name and descriptive properties;

made up of lower level Enterprise Objects (Sub-Objects) and/or Information Elements, as described by means of Object Abstraction Mechanisms. Conversely, Super-Objects can be constructed from lower level Enterprise Objects.

Event

Abbreviation: none

Source Document: Part I/B11-23007

(solicited and unsolicited) real-world happening, timer or request to do something in the enterprise or its environment. It can carry information(defined as Object View). It used to trigger the execution of one or more Domain Processes (and hence indirectly activates an employed Business Process/Enterprise Activity) by initiating the processing of their associated set of Behavioural Rules. It may also be used to condition the flow of control of a Business Process within a Domain Process.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


F
CIMOSA Glossary

Formal Reference Base

Abbreviation: FRB

Source Document:  None.

AMICE project central documentation base defining the CIMOSA architecture; structured hierarchically into a set of 'Items', each describing a small part of the overall architecture.

FRB = Formal Reference Base

Source Document:  None.

AMICE project central documentation base defining the CIMOSA architecture; structured hierarchically into a set of 'Items', each describing a small part of the overall architecture.

Function Input

Abbreviation: none

Source Document: Part I/B11-22308

Building Block component defined as a set of Object Views which are operated on during the execution of a an Enterprise Activity in order to produce the Function Output. Function Input can also apply to Domain Process and Business Process.

Function Output

Abbreviation: none

Source Document: Part I/B11-22408

Building Block component defined as a set of Object Views which are produced by an Enterprise Activity as the result of its execution. Function Output can also apply to Domain Processes and Business Processes.

Function View

Abbreviation: none

Source Document: Part I/B0-31008 - Function View

describes the functional structure, the functionality, and behaviour (i.e. rues which define the process sequence or flow of action and control within an enterprise) as well as the inputs and outputs of the underlying functions required to satisfy the requirements (i.e. objectives and constraints or manufacturing strategies) of an Enterprise.

Functional Entity

Abbreviation: none

Source Document: Part I/B32-22208

active Resource able to perform, completely on its own, a (class of) Functional Operation(s). A Resource which is classified as a Functional Entity must be able to communicate with the IIS and to process the relevant external protocol (Human Dialogue Service, Machine Dialogue Service, Application Dialogue Service) of its Presentation Services

Functional Operation

Abbreviation: none

Source Document: Part I/B12-24208

basic unit of work in the Design Specification Model (or lowest level of granularity in the Function View). At run-time it is fully executed or not at all. It consists of a name, a reference to a Functional Entity and a list of arguments including a status code.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


G
CIMOSA Glossary

Generic Building Block

Abbreviation: none

Source Document: Part I/B0-71008 - Generic Building Block

generalisation (abstraction) of all Building Blocks (Types, Partial, Particular) instantiated from it. It contains a minimum set of attributes common to those Building Blocks.

has the nature of an object class and therefore is defined by its name, a finite list of elements (either atomic properties defining descriptive characteristics or structured elements) and rules constraining the set of possible values for each element.

Generic Level

Abbreviation: none

Source Document: Part I/B0-51009 - Generic Level

subdivision of the CIMOSA Reference Architecture.

defines the full reference set of CIMOSA Generic Building Blocks and Building Block Types, and their rules and constraints for use in creating models at the Partial Level and Particular Level via the CIMOSA Model Creation Process.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


H
CIMOSA Glossary

Horizon

Abbreviation: none

Source Document: Part I/B0-1200 - Decision System of an Enterprise

time scale on which decisions can be taken with a determined degree of confidence.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


I
CIMOSA Glossary

IDM = Implementation Description Model

Source Document: Part I/B0-4300 - Implementation Description Modelling Level

expresses all the functional, information, resource and organisational business implementation requirements of a CIM system including exception handling conditions.

expresses the implementation requirements of a CIM system using the CIMOSA Function, Information, Resource and Organisation Views.

provides both user and system designer representation.

Implementation Description Model

Abbreviation: IDM

Source Document: Part I/B0-4300 - Implementation Description Modelling Level

expresses all the functional, information, resource and organisational business implementation requirements of a CIM system including exception handling conditions.

expresses the implementation requirements of a CIM system using the CIMOSA Function, Information, Resource and Organisation Views.

provides both user and system designer representation.

Implementation Description Modelling Level

Abbreviation: none

Source Document: Part I/B0-430010 - Implementation Description Modelling Level

describes the means and /or rules to be used in executing the enterprise operations as described at the Requirements Definition Modelling Level

defines constructs applicable for use at each of the CIMOSA Generic, Partial and Particular Levels.

Implemented External Schema

Abbreviation: none

Source Document: Part II/B23-2400!0

used to define the implementation description of External Schemata of the Information View in the physical Information System of the CIM system.

Information

Abbreviation: none

Source Document: Part I/B0-1300 - Information System of an Enterprise

meaningful interpretation and correlation of some aggregation of data in order to allow one to make decisions or to communicate.

Information Element

Abbreviation: none

Source Document: Part I/B21-2120!0

used to represent any item of information which, for the purposes they are being used, are indivisible i.e. atomic in an Enterprise Object or one of its Object Views. Each Information Element is defined on a given data type.

Information System of an Enterprise

Abbreviation: none

Source Document: Part I/B0-130010 - Information System of an Enterprise

part of the enterprise representing the processes and functions for short term and long term data and information processing/storage/maintenance according to the needs of the user and applications of the Decision System and the Physical System of the Enterprise.

Information View

Abbreviation: none

Source Document: Part I/B0-320011 - Information View

describes the information and information structure required by and in support of the functions defined in the Function View.

Instance

Abbreviation: none

Source Document: Part I/B0-730011 - Building Block Instance

user-defined individual of Generic Building Block or Building Block Type, The characteristics of which (i.e. elements) have been partially (Partial Level) or fully (Particular Level) defined.

Instantiation Process

Abbreviation: none

Source Document: Part IV/D0-1100

CIMOSA architectural principle which suggests (1) to go from generic to particular and (2) to re-use previous models as much as possible in the creation of the Particular Architecture of an enterprise.

covers:

-	Instantiation of Partial Models from Generic Building Blocks or from Building Block Types,

-	Instantiation of a Particular Model from Generic Building Blocks or from Building Block Types, and

-	Instantiation of a Particular Model from one or more Partial Models.

An Instantiation Process is defined for each Modelling Level and can be further defined for each CIMOSA View.

Integrated Enterprise Engineering Environment

Abbreviation: IEEE

Source Document: Part I/C1-1000

provides support for the design and modification of the Enterprise system which is an ongoing activity needing an engineering discipline.

Integrated Enterprise Operation Environment

Abbreviation: IEOE

Source Document: Part I/C2-1000

provides support for executing the Business Processes contained within the released Implementation Description Model; consists of:

-	the released Particular Implementation Description Model;

-	the relevant Services of the Integrating Infrastructure; and

-	a set of Implemented Functional Entities specific to the Enterprise (machines, people and application programs).

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


J
CIMOSA Glossary

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


K
CIMOSA Glossary

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


L
CIMOSA Glossary

Life Cycle

Abbreviation: none

Source Document: Part I/B0-4000 - CIMOSA Modelling Levels

definition of the model and system life cycle phases (Requirement Definition, Design Specification and Implementation Description).

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


M
CIMOSA Glossary

Manufacturing Enterprise

Abbreviation: none

Source Document: Part I/B0-1000 - Enterprise

Enterprise entity created for the purpose of producing manufactured goods from raw materials or basic components.

any manufacturing enterprise is composed of three major sub-systems: a Physical System, a Decision System and an Information System. These sub-systems are highly interrelated and any enterprise model describing any of the sub-systems has to recognise these relations.

Modelling Levels

Abbreviation: none

Source Document: Part I/B0-400012 - CIMOSA Modelling Levels

level of abstraction corresponding to the main life cycle phases of enterprise model development. It contains Generic Building Block and Building Block Types at the Generic Level and models at the Partial and Particular Level

Modelling View

Abbreviation: none

Source Document: Part I/B0-3000 - CIMOSA Views

abstraction viewpoint of one total model which emphasises some particular aspects of the model and disregards others for ease of analysis. is described by a set of constructs.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


N
CIMOSA Glossary

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


O
CIMOSA Glossary

Object Abstraction Mechanism

Abbreviation: none

Source Document: Part I/B21-211012

semantic links used to connect Enterprise Objects to one another to form a semantic information model of the Information View at the Requirements Definition Modelling Level; are defined within Enterprise Object descriptions.

Object Relationship

Abbreviation: none

Source Document: Part I/B21-260013

describes a user-defined relation between two Enterprise Objects of the enterprise Information System.

Object View

Abbreviation: none

Source Document: Part I/B21-220013

description of one aspect of one or more Enterprise Objects. It therefore describes a subset of properties owned by one or more Enterprise Objects from a given standpoint. It is made of Information Elements and/or Object Views.

Objective/Constraint

Abbreviation: none

Source Document: Part I/B11-290013

describe goals to be achieved by and restrictions to be imposed on Domains, Domain Processes, Business Processes, and Enterprise Activities.

Occurrence

Abbreviation: none

Source Document: Part I/B0-740013 - Building Block Occurrence

run-time copy of a particular Building Block Instance as required during execution within the Enterprise Operation Environment.

Organisational Cell

Abbreviation: none

Source Document: Part I/B41-210013

description of an organisational area.

describe generalised, real or abstract, uniquely identified, entities of the enterprise formal organisational structure, and are characterised by their unique identity, their name and descriptive properties. Each Organisational Cell contains at least one relationship to an Organisation Unit.

Organisational Constraints

Abbreviation: none

Source Document: Part I/B41-310013

describe restrictions imposed on the structure of the organisation of an enterprise.

Organisational Element

Abbreviation: none

Source Document: Part I/B42-230013

represents an area of responsibility as well as an area of authority of apart of a job description which represents the atomic level of the Organisation View. The construct offers the possibility to specify different degrees of responsibility and authority for the different Specified Organisation Elements.

Organisational Guidelines

Abbreviation: none

Source Document: Part I/B41-310013

describe a broad outline of the ideas on how to structure the organisation of an enterprise.

Organisational Relationship

Abbreviation: none

Source Document: Part I/B41-240013

describes the relationships between different objects (e.g. Cells depicted by specific Building Blocks) of the enterprise organisation.

Organisational Unit

Abbreviation: none

Source Document: Part I/B41-220013

representation of a job description (position). it is related to an Organisation Cell by exactly one relationship.

Organisation View

Abbreviation: none

Source Document: Part I/B0-3400 - Organisation View

describes an enterprise organisation structure, responsible and authorised for processes, functions, control, information and resources as defined in the Function, Information and Resource View.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


P
CIMOSA Glossary

Partial Design Specification Model

Abbreviation: none

Source Document: Part I/B7-110013

contains sets of (partial) instances of Generic Building Blocks and building Block Types structured to present a partial solution to problem areas in manufacturing enterprises. These partial solutions will be used as macro building blocks in the generation of Particular Design Specification Models.

Partial Implementation Description Model

Abbreviation: none

Source Document: Part I/B8-110013

contains sets of (partial) instances of Generic Building Blocks and building Block Types structured to present a partial solution to problem areas in manufacturing enterprises. These partial solutions will be used as macro building blocks in the generation of Particular Implementation Description Models.

Partial Level

Abbreviation: none

Source Document: Part I/B0-520013 - Partial Level

subdivision of the CIMOSA Reference Architecture.

defines a reference catalogue of partially-instantiated models, and the rules and constraints for their use in creating models at the Particular Level via the CIMOSA Model Creation Processes.

Partial Model

Abbreviation: none

Source Document: Part I/B0-5200 - Partial Level

represent similar characteristics for common parts of manufacturing enterprises, very often belonging to a given industry segment.

a set of partially instantiated Generic Building Blocks or Building Block Types which are related to each other.

configuration rules, which define which combination of constructs a Partial Model is allowed to contain and

consistency rules which define which relationships are allowed in a consistent model

Partial Requirements Definition Model

Abbreviation: none

Source Document: Part I/B6-110014

contains sets of (partial) instances of Generic Building Blocks and building Block Types structured to present a partial solution to problem areas in manufacturing enterprises. These partial solutions will be used as macro building blocks in the generation of Particular Requirement Definition Models.

Particular Design Specification Model

Abbreviation: PDSM

Source Document: Part I/B7-120014

consistent instantiation of CIMOSA Generic Building Blocks and Building Block Types or Partial Models for design specification in order to specify the static and dynamic properties of the operational system of a particular enterprise.

is unique to a given enterprise, and as such does not form part of the CIMOSA Reference Architecture.

Particular Implementation Description Model

Abbreviation: PIDM

Source Document: Part I/B8-120014

consistent instantiation of CIMOSA Generic Building Blocks and Building Block Types or Partial Models for the implementation description in order to describe how business operations of a particular enterprise are implemented and execute.

is unique to a given enterprise, and as such does not form part of the CIMOSA Reference Architecture.

Particular Level

Abbreviation: none

Source Document: Part I/B0-530014 - Particular Level

contains the models of the CIMOSA Particular Architecture.

defines the fully instantiated models of a CIM enterprise created either from the Generic or Partial Level via the CIMOSA Model Creation Processes.

represents specific characteristics of a particular enterprise by means of sets of fully instantiated Generic Building Blocks, Building Block Types or Partial Models

Particular Requirements Definition Model

Abbreviation: PRDM

Source Document: Part I/B6-120014

consistent instantiation of CIMOSA Generic Building Blocks and Building Block Types or Partial Models for requirements definition in order to express the business requirements of a particular enterprise.

is unique to a given enterprise, and as such does not form part of the CIMOSA Reference Architecture.

PDSM = Particular Design Specification Model

Source Document: Part I/B7-120014

consistent instantiation of CIMOSA Generic Building Blocks and Building Block Types or Partial Models for design specification in order to specify the static and dynamic properties of the operational system of a particular enterprise.

is unique to a given enterprise, and as such does not form part of the CIMOSA Reference Architecture.

Physical System

Abbreviation: none

Source Document: Part I/B0-110014 - Physical System of an Enterprise

represents the set of physical resources and pieces of equipment, the materials and goods, the human resources, and the physical Enterprise infrastructure used to transform raw materials or components into finished products).

PIDM = Particular Implementation Description Model

Source Document: Part I/B8-120014

consistent instantiation of CIMOSA Generic Building Blocks and Building Block Types or Partial Models for the implementation description in order to describe how business operations of a particular enterprise are implemented and execute.

is unique to a given enterprise, and as such does not form part of the CIMOSA Reference Architecture.

PRDM = Particular Requirements Definition Model

Source Document: Part I/B6-120015

consistent instantiation of CIMOSA Generic Building Blocks and Building Block Types or Partial Models for requirements definition in order to express the business requirements of a particular enterprise.

is unique to a given enterprise, and as such does not form part of the CIMOSA Reference Architecture.

Procedural Rule see Behavioural Rule

Abbreviation: none

Source Document: Part I/B11-271015

Process Behaviour

Abbreviation: none

Source Document: Part I/B12-231015

defines the internal behaviour (or flow of control) of Specified Enterprise Activities of the Design Specification Model. It specifies how to perform the functionality of an Enterprise Activity in terms of an algorithm making use of Functional Operations.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Q
CIMOSA Glossary

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


R
CIMOSA Glossary

RDM = Requirements Definition Model

Source Document: Part I/B6-100015

consistent instantiation of CIMOSA Generic Building Blocks and/or Building Block Types and/or Partial Models for requirement definition in order to express the business requirements of a particular enterprise.

mutual consistent set of fully instantiated constructs of the RDM level of the CIMOSA Reference Architecture (Generic and Partial Level.

Requirements Definition Model

Abbreviation: RDM

Source Document: Part I/B6-100015

consistent instantiation of CIMOSA Generic Building Blocks and/or Building Block Types and/or Partial Models for requirement definition in order to express the business requirements of a particular enterprise.

mutual consistent set of fully instantiated constructs of the RDM level of the CIMOSA Reference Architecture (Generic and Partial Level.

Requirements Definition Modelling Level

Abbreviation: none

Source Document: Part I/B0-410017 - Requirements Definition Modelling Level

defines what has to be done in a business sense and terminology, in terms of enterprise activities and without reference to implementation options or decisions.

Resource

Abbreviation: none

Source Document: Part I/B32-220017

has a Capability Set characterising the functional, object related, performance and operational attributes of the Resource.

distinguished between active resource objects (Functional Entities) and passive resource objects (Resource Components).

used by a Resource Input of some Enterprise Activities and is subject to a resource scheduling activity.

Resource Cell

Abbreviation: none

Source Document: Part I/B32-224017

behaves as a Resource.

permanent aggregation of Functional Entities and/or Resource Components; considered as a whole (Functional Entity).

can be a physical aggregation, describing the physical arrangement of Resources in the Enterprise or

can be a logical aggregation, based on classes of Resources or Enterprise Activities they support.

Resource Component

Abbreviation: none

Source Document: Part I/B32-221017

passive Resource. It is a physical object that provides a specified functionality, but cannot perform Functional Operations on its own, its command set is empty. A Resource Component cannot be further decomposed.

Resource Input

Abbreviation: none

Source Document: Part I/B11-227017

described by the relevant set of the Resource View (at the RDM Level). The Resource choice itself is a design task.

Resource Output

Abbreviation: none

Source Document: Part I/B11-228017

Building Block Component defined as a set of textual statement recording information about the usage of resources of an Enterprise Activity (at the RDM Level). Can also apply to Domain Processes or Business Processes.

Resource Set

Abbreviation: none

Source Document: Part I/B32-223017

behaves as a Resource.

fully supports a (class of) Enterprise Activities as Resource Input.

a temporary physical aggregation of Functional Entities and/or Resource Components in the Enterprise Operation Environment; considered as a whole (Functional Entity).

a permanent logical aggregation of Functional Entities and/or Resource Components if defined in the Enterprise Engineering Environment.

Resource View

Abbreviation: none

Source Document: Part I/B0-330018 - Resource View

describes the required capabilities, the resources and their structure and location and the capabilities provided by the resources of the enterprise which perform the functions defined in the Function View

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


S
CIMOSA Glossary

Specified Business Process

Abbreviation: none

Source Document: Part I/B12-230018

construct used to represent a Business Process within a Design Specification Model. It may have Resource Input and its set of Behavioural Rules is describes in terms of a Process Behaviour specification.

Specified Domain

Abbreviation: none

Source Document: Part I/B12-210018

description of a CIMOSA Domain in the Function View of the Design Specification Model. It provides a "Table of Contents" for the part of the enterprise being analysed, providing the list of specified constructs making up the Domain for the purpose of model design, simulation and validation.

Specified Domain Process

Abbreviation: none

Source Document: Part I/B12-220018

construct used to represent a Domain Process as it stands at the top of a functional decomposition within a Specified Domain of the Design Specification Model. Its set of Behavioural Rules is described in terms of a Process Behaviour specification.

Specified Enterprise Activity

Abbreviation: none

Source Document: Part I/B12-240018

construct used to represent enterprise functionality within a Specified Domain at the Design Specification Modelling Level. It is defined by its Function Input, Control Input, Resource Input, Function Output, Control Output, Resource Output, Ending Status and Activity Behaviour. The Activity Behaviour specification indicates how Functional Operations are employed to realise the functionality of the Enterprise Activity.

Specified Event

Abbreviation: none

Source Document: Part I/B12-250018

a fact specifying a request to do something or a real world happening occurring at a given instant in time from a given source and indicating a change in the state of the enterprise.

System Life Cycle

Abbreviation: none

Source Document: Part I/D1-1010

definition of the development and operational phases of a CIMOSA system; consists of five major Business processes:

-	System Requirements Specification,

-	System Design,

-	System Build and Release,

-	System Operation, and

-	System Change.

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


T
CIMOSA Glossary

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


U
CIMOSA Glossary

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


V
CIMOSA Glossary

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


W
CIMOSA Glossary

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


X
CIMOSA Glossary

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Y
CIMOSA Glossary

(c)  1993 - 1996 CIMOSA Association. All rights reserved.


Z
CIMOSA Glossary

(c)  1993 - 1996 CIMOSA Association. All rights reserved.