Towards an Approach to Model Business Processes using Workflow Modeling Techniques in Production Systems

Transcription

1 Proceedings of the 34th Hawaii International Conference on System Sciences Towards an Approach to Model Business Processes using Workflow Modeling Techniques in Production Systems Ricardo M. Bastos, Duncan Dubugras A. Ruiz Faculdade de Informática Pontifícia Universidade Católica do Rio Grande do Sul Porto Alegre - RS Brasil {bastos,duncan}@inf.pucrs.br Abstract This work presents an object-oriented approach to model business processes in production systems using workflow concepts. We define an object reference model called C-Wf that represents the structural and functional enterprise elements involved in the business processes, such as enterprise activities, human resources, machines, etc. Through the C-Wf reference model classes it is possible to build up particular enterprise models that involve the elements required to the production planning process and the basic information for monitoring business processes execution under a workflow point of view. We discuss the essential aspects involved on the production planning, in particular at the resource allocation process, which are addressed by the proposed approach.. Introduction At the last two decades there is a strong efforts towards the enterprise modeling and integration standardization. One of the main results is concentrated at the IFAC IFIP Task Force GERAM (Generalized Enterprise Reference Architecture and Methods). GERAM is a generalization of CIMOSA (Computer Integrated Manufacturing - Open Systems Architecture), among others. It provides a methodology for enterprise engineering, a system life cycle and constructs for modeling. On the other side, the Workflow Management Coalition (WfMC) is a non-profit international organization that has been founded in 993 by a number of users, vendors and analysts of Workflow Management Systems (WfMS). WfMC has the objective of establishing standards for workflow terminology, connectivity and interoperability, permitting the investment protection when customers move from one WfMS implementation to another. Some works [, 2] have been developed trying to use CIMOSA and WfMC reference models. The main contributions are applications that show the possibility of the integration between these models. In this work, we present the C-Wf model, which formally defines a reference model to become feasible the directly utilization of a workflow tool compatible with the WfMC in an enterprise modeled through the CIMOSA. Considering that a WfMS propitiates monitoring the business processes execution, as well the assignment of resources for its accomplishment, one of the most important contributions of the C-Wf is to present a reference model that considers the elements required supporting a resource allocation method. In this paper we describe the C-Wf model presenting its classes and discussing its validity as a reference model for the definition of methods for resource allocation planning and monitoring. In this sense, we (i) identify the main aspects which must be observed in a resource allocation planning model, (ii) examine the main classes and concepts about CIMOSA and WfMC, and (iii) specify the C-Wf as an extension of both CIMOSA and WfMC models. 2. The resource allocation process The production systems may be characterized by its products, material consumed, components or subassemblies used in the products, the production operations and the production resources allocated to these operations. The products are nothing more than the results of the system s effort as a whole. During the production process the material is consumed and the production resources are used. These production resources are employed at the execution of each production activity that composes the manufacturing route for a final product. The production resources are essentially the machines, equipment and labor available in the production system and they have limited capability /0 $0.00 (c) 200 IEEE

2 Proceedings of the 34th Hawaii International Conference on System Sciences Considering that production activities consume resources a fundamental aspect to be noticed when planning the production is the resource allocation process. Production planning is essentially a decision-making process, which make available a set of resources to respond a certain event, for example, a production order. A detailed planning, generated through scheduling algorithms must result on manufacturing calendars that specify which activity must be performed at each instant on time for every resource. Any production planning process must basically consider: (i) each final item s production route - set of the activities necessary to manufacture the item, showing the precedence relationship to be observed when executing them, (ii) the resources to be used in each activity anticipated in the routes, (iii) the limits of each resource s capability, (iv) the execution time of each activity - for each item related to the resources used, (v) the resources set-up time and (vi) the deadlines for each item. Having these aspects in mind, it is possible to conclude that the complexity in the production planning decision-making process is on searching an ideal level of resource utilization, which implies fundamentally on searching the best resources allocation at each moment aiming to satisfy the existing demand. One of the main components of the complexity is the frequent disturbance occurring in the shop floor. These disturbances occur due to new requirements, modifications of the previous requirements, production malfunctions and other perturbations of the planned schedule. The immediate consequence is a change in the production schedule. In order to manage the changes, the production planning process must consider the deadlines defined for each production event, the local resources constraints and the global constraints of the production system. The main aspects which must be observed in a resource allocation planning model could be divided in three groups: (i) the features and properties of the production resources, (ii) production process of products, and (iii) the resource allocation process [3]. 2.. Resources properties The main constraints that must be evaluated in order to identify whether a production resource is qualified to execute a production operation are: Quality standard: a resource must be qualified to execute a production operation according to its standard quality specification. Schedule constraints: each production resource must have an agenda in which must be schedule its commitments. Each commitment concerns on a production operation involving a collection of parts or raw material. So, for each production operation that the resource is qualified to execute must be defined a standard production time. Based on this standard production time and the volume of parts or raw material involved it is possible to define the amount of time required for the production operation execution. Considering the amount of time required and the deadline to accomplish the production operation, it is possible to define the capacity of the resource to attend the demand and consequently to schedule this new commitment at its agenda. It is important to notice that it could be necessary the set-up of the resource before executing the production operation. The time required for the set-up must be computed with the total time required to execute the production operation. As we can see, these temporal variables must be constantly updated for each production resource, in order to allow its schedule process. Production constraints: a production resource has production constraints in two main aspects: (i) the number of hours per day that could be used in the production process, and (ii) its time interval production capacity, as for example, number of piece that could be produced in a work day, limit of hours that the resource could work without maintenance, etc. It is important to consider that in order to do the set-up of a resource it may be necessary to allocate other resources. Thus, this kind of resource must be considered in the resource allocation process. This information must compose the knowledge base of each production resource, such as the temporal variables explained above Products In order to assign all the resources required to accomplish the production process of product, it is necessary to consider: the composition of each alternative production route, considering the constraints of sequence and synchronization among the production activities required to manufacture the product; strategies and mechanisms to choose the best production route (if there is more than one alternative production route) that consider the situation of each resource required to attend the production activities in terms of its occupation level; the production order deadline Resources allocation Considering the aspects examined above, under a resource allocation perspective it is necessary to specify: /0 $0.00 (c) 200 IEEE 2

3 Proceedings of the 34th Hawaii International Conference on System Sciences a resource allocation strategy which consider the necessity of the production system reacts in a dynamic way to attend the demand; procedures that avoid additional production costs, as for example set-up costs or intermediate stock formation, complementing the aspects above explained; mechanisms to permit coalition formation among resources in order to attend some production activities that requires joint action (as for example a machine and an operator), and consequently schedule synchronization; rules to guarantee that the commitments assumed by the production resources will be accomplished; mechanisms to treat disturbances that affect the production process in real time. In order to treat these disturbances it is necessary to re-schedule the resource commitments affected, avoiding deadline delay; a mechanism to find the best distribution of the production operations among the resources in a balanced way. It means assigning each required production operation to the resource instance that presents both lower occupation level (reducing the surcharge for some resource instance) and lower production cost (reducing the production costs) at the time interval required. 3. The business process modeling Considering that we are especially interested in the structural and functional aspects involved in a production system, like IFAC IFIP Task Force GERAM we decide to adopt CIMOSA as a reference model. CIMOSA is an ESPRIT project by the AMICE Consortium (European CIM Architecture) formed by a group of 22 European companies, universities and research centers. According [4], CIMOSA essentially intends to provide means to: - develop enterprise models in an evolutionary form through modular enterprise modeling; - define, describe and structure the enterprise s requirements in a consistent and significant manner; - derive the system s project and both relevant and sufficient specifications of the enterprise components from these requirements; - make possible the maintenance of the enterprise model (adapted to internal and external circumstances). Based on CIMOSA definitions it is possible to build an enterprise model that represents all the business processes, its respective properties in terms of enterprise activities and the resources required for its execution. Table shows some basic CIMOSA terms extracted from [5], and figure exhibits a partial CIMOSA UML class diagram representing the main classes of the enterprise model. Event triggers Business Process executed Functional Entity Domain Process Enterprise Activity Functional Operation Figure. CIMOSA UML partial class diagram. Table. CIMOSA modeling classes' partial list. Behavioral Rule: Building Block component, which describes the desired action(s) to be taken in the flow of control of a DP or a BP. Business Process (BP): Describes pieces of enterprise behavior at all level of decomposition of the functional decomposition except the top and bottom levels. It is triggered by a parent structure (DP or BP). Domain Process (DP): Triggered by means of at least one Event and nothing else than Events and producing a defined end result (Function Output). It encapsulates a well-defined set of enterprise functionalities and behavior (i.e. EA and BP) to realize clearly defined objectives under given constraints. Enterprise Activity (EA): Defines 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. It is employed by one or more DPs and/or BPs, but does not employ any BP or EA. Event: (solicited and unsolicited) real-world happening, timer or request to do something in the enterprise or its environment. Functional Entity: Active Resource able to perform, completely on its own, a (class of) Functional Operation(s). Functional Operation: Basic unit of work at the lowest level of granularity in the Function View. At run-time it is fully executed or not at all. Considering the CIMOSA, from a conceptual point of view, a Domain Process is functionally decomposed into Business Processes and Enterprise Activities. A Business Process represents an aggregation of Enterprise Activities. Both of them could be used in different Domain Processes. The Enterprise Activities involve one or more Functional Operations that are executed by the Functional Entities. Functional entities represent the production resources. An Enterprise Operation Environment [6] manages the execution of a Domain Process. It controls the execution of a released Implementation Description Model that is /0 $0.00 (c) 200 IEEE 3

4 Proceedings of the 34th Hawaii International Conference on System Sciences used to drive the enterprise operation and monitor and control the desired product life cycles. It receives production events and creates occurrences of the related Domain Process and all its contents. It generates, schedules and executes instances of Domain Process, Business Processes and the underlying network of Enterprise Activities, which represent the model, and associated Functional Operations. Business Processes and Enterprise Activities compose a Domain Process defining a production route. A Behavioral Rule Set defines the logical sequence of Business Processes and Enterprise Activities within a Domain Process. The Behavioral Rule Set specifies the conditions to be satisfied by each activity before starting its execution. 3.. Enterprise Activities According Vernadat [7], an Enterprise Activity is characterized by: () a name or identifier, (2) a description, (3) function, control and resource inputs and outputs, (4) minimum and maximum durations (may be an average duration with standard deviation), (5) an activity behavior, (6) set of required capabilities, and (7) an exact list of ending statuses. Enterprise Activities may be classified as Machine Activities (without human intervention), Human Activities, Hybrid Activities, and Co-operative Activities. Also, Vernadat [7] presents a way to specify the activity behavior in terms of: preconditions, statements, post-conditions, ending statuses and exceptions Business Processes Vernadat [7] also characterizes Business Processes by: () name or identifier, (2) set of triggering events, (3) process behavior, and (4) set of ending status. The specification of process behavior is done by a set of WHEN (condition) DO action rules Behavioral Rules The CIMOSA Behavioral Rules [8] for structured processes are showed in Table 2. Based on these classes definitions and the behavioral rules it is possible to build a workflow model that allows the monitoring of the execution of a domain process occurrence. Moreover, the model could be used to support an optimization process for both resource allocation and production scheduling since it permits to make available and identify the information required to fulfil the aspects presented at the previous section. At the sequence we are presenting a brief discussion about workflow modeling, and a model integrating the workflow and CIMOSA concepts. Based on this model, we are examining the application of this approach at the resource allocation considering the aspects presented at the precedent section. Table 2. CIMOSA Behavioral Rules Process triggering rules: they are used to start a process with or without events (without events means that the business process EF is just called by a parent process). WHEN (START WITH event-) DO EF WHEN (START WITH event- AND event-2) DO EF WHEN (START) DO EF Sequential rules: they are used to represent branching conditions in the flow of control. ES(EFi) is a pre-defined function returning the ending status after completion of EFi, ANY is a reserved word representing all the possible ending status of EFi, and end-status-n represents a specific ending status of EFi. WHEN (ES(EF) = ANY) DO EF2 (also called forced sequential rule) WHEN (ES(EF) = end-status-) DO EF2 (also called conditional sequential rule) Spawning rules: they are used do represent the parallel execution of EFi; & is the parallel operator, and SYNC is a reserved word meaning the simultaneous start of EF2, EF3 and EF4: WHEN (ES(EF) = end-status-) DO EF2 & EF3 & EF4 (also called asynchronous spawning) WHEN (ES(EF) = end-status-) DO SYNC(EF2 & EF3 & EF4) (also called synchronous spawning) Rendezvous rules: they are used to synchronize the end of spawning rules: WHEN (ES(EF) = end-status- AND ES(EF2) = end-status-2 AND ES(EF3) = end-status-3) DO EF4 Loop rules: they are used to execute the same EFi iteratively: WHEN (ES(EF) = loop-value) DO EF WHEN (ES(EF) = exit-value) DO Efx Process end rules: they are used to indicate the end of the process: WHEN (ES(EF) = end-status-) DO FINISH 4. Workflow modeling It is considered the basic concepts defined on the Workflow Reference Model [9, 0, ] from WfMC. Figure 2 shows a UML class diagram representing the relationships between the basic concepts defined by WfMC. The main functionalities offered by a typical WfMS are [9]: () the definition and modeling of the workflow processes and its constituent activities, (2) the management of the workflow processes in an operational environment and sequencing of various activities to be handled as part of each process, and (3) the control of the interactions with human users and Information Technology (IT) application tools for processing the various activity steps. Table 3 shows some of the basic concepts, extracted from []. The basic concepts may be divided into two main contexts: () Process design and definition, and (2) Process instantiation and control. This division can roughly be seen in the figure 2, where its left side corresponds to the context () and its right side corresponds to the context (2). In the context of process /0 $0.00 (c) 200 IEEE 4

5 Proceedings of the 34th Hawaii International Conference on System Sciences design and definition, it is defined all the activities and the connections among them. These connections can specify sequential and/or parallel routing of the activities. According [], there are 6 different routing possibilities: (a) single thread, (b) and-split, (c) and-join, (d) or-split, (e) or-join, and (f) iteration. The meaning and a diagram sample of each of them are showed in table 4. Sub-process Business Process defined in managed by Process Definition Workflow Management System used to create & manage via composed of from Process Activity Transition to include Manual Activity Automated Activity Activity responsible which include include Workflow Participant performed by Work Item Invoked Application Figure 2. WfMC UML partial class diagram. Table 3. Some WfMC basic concepts []. Activity: A description of a piece of work that forms one logical step within a process. A workflow activity requires human and/or machine resources(s) to support process execution. Business process: A set of one or more linked procedures or activities that collectively realize a business objective or policy goal. Invoked application: An invoked application is a workflow application that is invoked by the WfMS to automate an activity, fully or in part, or to support a workflow participant in processing a work item. Process: The representation of a business process in a form that supports automated manipulation by a WfMS. Process and Activity : The representation of a single enactment of a process, or activity within a process, including its associated data. Each instance represents a separate thread of execution of the process or activity, which may be controlled independently and will have its own internal state and externally visible identity. Transition: A point during the execution of a process instance where one activity completes and the thread of control passes to another, which starts. A transition may be ruled by one or more transition conditions. Workflow participant: A resource, which performs the work, represented by a workflow activity instance. This work is normally manifested as one or more work items assigned to the workflow participant via the work list. Work item: The representation of the work to be processed (by a workflow participant) in the context of an activity within a process instance. Work list: A list of work items associated with a given workflow participant (or in some cases with a group of workflow participants who may share a common work list). The work list forms part of the interface between a workflow engine and the work list handler. Besides the routing possibilities, it is possible to specify, at the process and activity levels, three different types of constraints: pre-conditions, post-conditions, and deadline. A pre-condition is a logical expression, which may be evaluated by a WfMS to decide whether a process instance or activity within a process instance may be started. A post-condition is a logical expression, which may be evaluated by a WfMS to decide whether a process instance or an activity within a process instance is completed. A deadline is a time based scheduling constraint, which requires that, a certain activity (or work item) be completed by a certain time. Hence, it is possible to define time-based (deadlines), resource-based (e.g. consumes less than ) and cost-based (e.g. costs more than ) constraints. Therefore, for the proper use of a WfMS, it is necessary to model the application domain in terms of business processes. A process (with occasional subprocesses), activities, transitions and constraints must represent each business process. Also, it is necessary to model the workflow participants in terms of their responsibilities and skills. Consequently, during the context of process instantiation and control (after the modeling context), the WfMS guarantees the right sequence of the activities being executed, controls the interactions among activities and workflow participants/invoked applications, and manages the work lists from the workflow participants /0 $0.00 (c) 200 IEEE 5

6 Proceedings of the 34th Hawaii International Conference on System Sciences Table 4. WfMC routing possibilities among activities []. Routing possibilities and Diagram samples (considering the natural execution flow: left to right) single thread: an activity can be executed after the completion of A A2 another. and-split: a single thread of control splits into two or more threads, which are executed in parallel within the workflow, allowing multiple activities to be executed simultaneously. A A2 A3 A4 and-join: a point in the workflow where two or more parallel executing activities converge into a single common thread of control. It is a synchronization point in the workflow. or-split: a point within the workflow where a single thread of control makes a decision upon which branch to take when encountered with multiple workflow branches. The decision is specified by transition conditions (e.g. C, C2 and C3). or-join: a point within the workflow where two or more alternative activity workflow branches re-converge to a single common activity as the next step within the workflow. Iteration: a workflow activity cycle involving the repetitive execution of one (or more) workflow activity(s) until a condition is met. C and C2 are transition conditions. 5. The C-Wf model A A2 A3 A A A2 A3 C C3 C2 A4 A2 A3 A4 A4 C A A2 A3 C2 We propose a mapping model, called C-Wf model (figure 3), from CIMOSA to WfMC basic concepts, which permits monitoring and control of Domain Processes execution by a WfMS. The goals are: () to capture all the necessary information of the description of a Domain Process, and (2) to complement the mapping with additional information required. Table 5 shows the mapping from CIMOSA modeling classes and classes instances to WfMC basic concepts and, finally, to C-Wf basic concepts. It is used different ways of notation for CIMOSA and WfMC to C-Wf basic concepts. The CIMOSA basic terms are presented in bold. WfMC basic concepts are presented underlined. The C-Wf classes and instances are presented in bold-italic. The terminology adopted by C-Wf model is the same as CIMOSA classes and instances, when possible. Organizational Cell and its Organizational Elements are mapped as an Organizational Model and its Organizational Entities. An Enterprise Object is mapped as an Application Data or a Relevant Data, and the set of Object Views for an Enterprise Object is mapped as a set of views of Application Data or Relevant Data. The views of Relevant Data determine which subset of the properties defined into a Relevant Data may be used by each different Activity. A Domain is defined basically by a set of business objectives and constraints and composed by a set of interactive Domain Processes. It corresponds to a set of Business Process. A Domain Process (DP) accomplishes part or whole domain objectives under given constraints. It corresponds to a Workflow of a Business Process, represented by a Process. Each Business Process (BP) when presented into a Domain Process corresponds to a Sub-Process. An Enterprise Activity (EA) is mapped as an Activity. The dynamics of the Domain Process and Business Process, defined by the Behavioral Rules, corresponds to Transitions with their Transition Conditions. An Enterprise Operation Environment is responsible for the creation and control of occurrences of the defined Domain Processes and initiates each instance of any Domain Process when receives one (or more) event. In a similar way, a Workflow Management System is responsible for the creation and control of occurrences of the defined Workflow of a Business Process and initiates each instance of any Workflow when receives one (or more) events. As a consequence, Domain Process, Business Process and Enterprise Activity, corresponds respectively to Process, Sub-Process and Activity. For the execution control of an Activity, a WfMS offers a special software service, called Work list handler. When an Activity that requires a human intervention is ready for execution, it is assigned to a proper workflow participant (or a set of them with the same organizational role) inserting the Activity in his/her work list. For the point of view of the workflow participant, there is a set of work items to be executed, in his/her work list, managed by the work list handler. There aren t specific CIMOSA terms to support these WfMC concepts. In fact, the Enterprise Operation Environment internally implements this type of functionality. Resources and the related terms (Functional Entity, Functional Operation, Capability, Capability Set) aren t directly mapped into WfMC concepts. CIMOSA define two basic types of resources [8]: components (passive resources without autonomy) and functional entities (with their set of functional operations) /0 $0.00 (c) 200 IEEE 6

7 Proceedings of the 34th Hawaii International Conference on System Sciences Functional entities and enterprise activities can be described by their set of capabilities (capability set). Event triggers Domain Process Domain Behavioural Rule ruled by ruled by 0.. Business Process 0.. Capability Set requires Enterprise Activity Functional Operation provides executed Functional Entity Human Application Machine CIMOSA defines three types of functional entities: humans, machines and applications. Application functional entities are mapped as Invoked applications, and human functional entities are mapped as Organizational Roles. In certain situations, an Organizational Role may have only one specific Workflow participant (e.g. the CEO of a company). In this case, a human functional entity may be mapped as a Workflow participant. WfMC mentions ([0]) without justification that an automatic machine may be considered as a workflow participant, and calls this type of workflow participant as a resource or a system. In fact, we believe it isn t possible to mapping a machine functional entity as a workflow participant or an invoked application. A machine functional entity is an active resource with a probable computerized controller within a set of services (methods) available, which is capable to interact with the Enterprise Operation Environment. Also, it is necessary to define in advance the appointments of a machine functional entity, maximizing the machine throughput and, consequently, reducing costs. 5.. Detailed mapping of DP, BP and EA Domain Process (DP), Business Process (BP) and Enterprise Activity (EA) are concepts that represent the functionalities and behavior of an enterprise model. For these concepts, it is important to refine the mapping model, in order to compare the properties of each of them in details. Table 6 presents the properties with a brief Figure 3. C-Wf UML partial class diagram. comment and where they are valid based on [6, 7 and 8]. A Process Behavior is defined as a set of behavioral rules, as showed in table 2. The connections among activities with routing possibilities are showed in table 4. The set of behavioral rules corresponds to the set of routing possibilities as showed in table 7. In special, Spawning rules: synchronous spawning doesn t have a direct mapping option into the set of routing possibilities. A possible way to map synchronous spawning is the use of and-split routing plus a set of deadline constraints. These deadlines must be defined according the expected duration time of each activity. In fact, this solution doesn t guarantee the simultaneous start of the activities. It would be necessary to extend the WfMC model to properly support the synchronous spawning behavioral rule. The Identifier, Name and Description are information that permits the comprehension of the process/ activity being modeled. They are mapped to equivalent WfMC concepts. Triggering events are events that start a Domain Process instance and are mapped to events because they have the same meaning. Required capabilities are the set of qualifications and skills (capability set) required from the functional entities to participate in the execution of an enterprise activity instance. WfMC doesn t offer equivalent concepts capable to support these CIMOSA modeling classes. Function inputs and outputs are mapped as application data or relevant data. Control inputs are mapped as relevant data, because they control and constraint the execution of the activity. Control outputs are mapped as relevant data, even a control output being an output event /0 $0.00 (c) 200 IEEE 7

8 Proceedings of the 34th Hawaii International Conference on System Sciences or an ending status, because a WfMS manages the transitions among activities based on the final values of the relevant data used by the activities. Therefore, the ending statuses of an enterprise activity and the occasional output events are mapped as relevant data. A discussion about the mapping of Resource Inputs and Resource Outputs (functional entities) was presented before. The Duration of an Enterprise Activity is mapped as Duration of an Activity. Table 5. Mapping from CIMOSA and WfMC to C- Wf basic concepts. CIMOSA Workflow C-Wf M o d e l i n g c l a s s e s I n s t a n c e s Behavioral Rule Transition and Transition Condition Behavioral Rule Business Process Sub-Process Business Process Capability Capability Capability Set Capability Set Domain Set of Business Domain Processes Domain Process Workflow of a Domain Process Business process Enterprise Activity Enterprise Activity Activity Enterprise Object Application Data Enterprise Object and Relevant Data Event Event Event Functional Entity (FE): human Organizational Role Functional Entity: human Functional Entity: application Invoked application Functional Entity: application Functional Entity: machine Not defined Functional Entity: machine Functional Operation Defined only for human and Functional Operation application FE Object View View of Object View Application Data / Relevant Data Organizational Cell Organizational Model Organizational Cell Organizational Organizational Organizational Element entity Element Business Process Sub-Process Business Process Domain Process Process Domain Process Enterprise Activity Enterprise Activity Activity Enterprise Operation Environment Workflow management system Workflow participant Work item Work list Work list handler C-Wf management system of Functional Entity: human of Functional Operation Functional Entity Agenda Agenda management system Table 6. Properties of Domain Process, Business Process and Enterprise Activity. Property name Valid on Comment DP BP EA (where adequate) Identifier / Name X X X Description X X X Objectives, Constraints, (textual form) Declarative Rules, Comprises and Where used Triggering events X List [,n] of events Required capabilities X List [,n] of capabilities Process Behavior X X Set of WHEN(condition) DO action rules Ending Statuses X X List [,n] of ending statuses Function Inputs X List [0,n] of object views Control Inputs X List [0,n] of object views Resource Inputs X List [,n] of resources Function Outputs X List [0,n] of object views Control Outputs X List [0,n] of events generated Resource Outputs X Information on resources statuses Activity Behavior X pre-conditions; sequence of functional operations; post-conditions Duration X Average, minimum and/or maximum Table 7. Mapping from Behavioral Rules to routing possibilities Behavioral Rule Routing possibility Process triggering rules: Start of a process Sequential rules: forced sequential rule Single thread Sequential rules: forced sequential rule Or-join (from the selected branch of a previous Or-split) Sequential rules: conditional sequential Or-split rule Spawning rules: asynchronous spawning And-split Spawning rules: synchronous spawning Not defined Rendezvous rules: And-join Loop rules: Iteration Process end rules: End of a process The Activity Behavior is decomposed in preconditions, a logically controlled sequence of functional operations and post-conditions. Pre-conditions and postconditions are mapped as pre-conditions and postconditions constraints, respectively. But, there isn t a way to describe a sequence of functional operations in the WfMC reference model. There are some activity attributes that may only document how each activity can be executed /0 $0.00 (c) 200 IEEE 8

9 Proceedings of the 34th Hawaii International Conference on System Sciences Resources allocation process based on the C-Wf model The integration between the CIMOSA and workflow techniques through the C-Wf model presents a reference model that allows the formalization of both the structure and functionality of an enterprise and describes its production processes as a workflow model. As a consequence, it is possible monitoring the execution of the production process occurrence using a workflow tool. Under a resource allocation process point of view, the C-Wf formally defines the concepts involved at the production process specifying a reference model that could be applied to become feasible the directly utilization of a workflow tool (compatible with the WfMC) in an enterprise modeled through the CIMOSA. Besides that, the model permits to examine the aspects involved in a resource allocation process in a consistent way due to the richness of information and rigorous of its semantic aspects. At the sequence, we examine the validity of the C-Wf as a reference model for the definition of methods that satisfy the resource allocation process requirements according the ones presented at section Resources properties According CIMOSA, each enterprise activity is composed by one or more functional operations, which in its turn requires a qualified functional entity for its execution. This relationship must be defined during the enterprise modeling process considering the skills required for a functional entity in order to execute a functional operation with an adequate quality level. Besides that, it is important to establish the general production constraints of the functional entity, such as the number of workday hours, as well as its particular production constraints, such as standard production time, set-up time, and so on. These aspects compose the main attributes of the functional operation and functional entity classes at the C-Wf model. The complementary basic information required for a resource allocation method as examined at the sections 2 and 3 are specified at the enterprise activity and functional operation classes of C-Wf model. However, it is possible to define new elements of information at the C-Wf classes in order to attend possible particular characteristics of a resource allocation method. As explained before, the main result of a resource allocation process execution is the scheduling of the commitments for each production resource. At the C-Wf model, a production resource is represented by a functional entity and their commitments are instantiated in its agenda. Based on the functional entity agenda of each functional entity instance it is possible monitoring the production process execution through a WfMS Products The main aspect about the products for the resource allocation process concerns on the production route. As explained before, at the C-Wf a production route is modeled as a workflow involving a domain process and its respective business processes and enterprise activities. Through the routing possibility or-split it is possible to define for a domain process or business process more than one configuration for its production route workflow. For an enterprise activity instance could be necessary the participation of more than one functional entity to perform its functional operations. In order to select and assign these functional entity instances the resource allocation method must use the work list of each one. Based on the functional entity work list it is possible to identify its availability to attend the enterprise activity occurrence Resources allocation We consider that a resource allocation method must be able to attend in a dynamic way all the production events that affect the production system, like new production orders, machine breakdown, raw material fault, production fail, workers fault, etc. For this purpose, the method must use the information about the status of the production system. The production system status is basically defined by the value of the attributes of each enterprise activity occurrence. In its turn, the value of the attributes of the enterprise activity occurrence is derived from the value of the attributes of each functional operation that is executed in order to accomplish the enterprise activity occurrence. These attributes concerns on the temporal values defined for the functional operation occurrence, as for example deadline, estimated execution time, time-out, as well as the status of its execution, as for example, time remaining, execution situation and so on. All these attributes are defined at the C-Wf model including the aspects related with the functional entity instances through its particular work list that defines its commitments and its situation in each work time period (basically available to order or not). Based on these information, the resource allocation method could execute algorithms that reschedule the commitment of the functional entity instances affected by the production event in order to avoid delays at the domain process or business process occurrences. Besides that, based on the functional operations that form each enterprise activity it is possible to identify the necessity of /0 $0.00 (c) 200 IEEE 9

10 Proceedings of the 34th Hawaii International Conference on System Sciences coalition formation among functional entity instances in order to attend all of them. This information must be used by the resource allocation method to synchronize the schedule of all the functional entity instances required to attend the enterprise activity occurrence. A workflow management system could be used to monitor the execution of all enterprise activity occurrences at the production systems and support the efforts to guarantee the commitments accomplishment of the functional entity instances. Based on the information from a workflow management system it is possible to verify disturbances at the enterprise activity execution and try to solve these situations through the resource allocation method. 7. Conclusion This work has presented a reference model called C- Wf, which is an extension of CIMOSA including workflow concepts from WfMC. We define the C-Wf generic classes and identify its relationships. The main contribution of C-Wf is the definition of a reference model that could be used to model an enterprise considering the concepts required in a workflow model. As a consequence, the C-Wf reference model defines the elements required to support a resource allocation process, as well the basic requirements for monitoring a business process execution. The essential aspects involved on the resource allocation process are discussed. Also, it is examined the validity of the C-Wf as a reference model for the definition of methods for resource allocation planning and monitoring. At present we are applying the C-Wf as a reference model for a multi-agent system called M-DRAP Multiagent Dynamic Resources Allocation Planning [3, 2, 3]. The M-DRAP has a strong conceptual correspondence with the CIMOSA, representing the organizational structure of typical production systems in a consistent way. This system defines a distributed planning process, in which every involved entity is able to realize resources allocation to fulfil the production requirements considering the temporal constraints. This model considers both temporal and synchronism aspects involved in the allocation process. The M-DRAP architecture supports the service encapsulation through the hierarchy of agents, to preserve their autonomy and capacity to make decisions considering their local plans. The M-DRAP system defines a strategy for dynamic resource allocation, which is able to treat disturbances in the production system, in real time. Based on C-Wf, we intend to improve the functionalities of M-DRAP system, including the workflow management system facilities. As a consequence, it will be possible to develop an integrated computerized environment that monitor the production processes and inform the M-DRAP agents in real time about the situation at the shop floor. 8. References [] M. Dickerhof, M. Didic, U. Mampel, Workflow and CIMOSA background and case study, Computers in Industry, Elsevier, Amsterdam, Nov. 999, pp [2] A. Ortiz, F. Lario, L. Ros, M. Hawa, Building a production planning process with an approach based on CIMOSA and workflow management systems, Computers in Industry, Elsevier, Amsterdam, Nov. 999, p [3] R.M. Bastos, Resource Allocation Planning using Multi- Agent Systems, PPGC-UFRGS, Porto Alegre Brazil, 998. (PhD Thesis, in Portuguese) [4] K. Kosanke, CIMOSA - A European development for enterprise integration - Part : an overview, In: Proceedings of st Int. Conf. on Enterprise Integration Modeling. MIT, 992. [5] CIMOSA Association (e.v.), CIMOSA Primer: Glossary of Terms. CNT, Gdansk-Poland, 996. (Accessed : 25/05/2000) [6] M. Zelm, F. B. Vernadat, K. Kosanke, The CIMOSA business modelling process, Computers in Industry, Elsevier, Amsterdam, Oct. 995, pp [7] F.B. Vernadat, CIM business process and enterprise activity modelling, In: Modelling and Methodologies for Enterprise Integration Proceedings of the IFIP TC5 Working Conference, Chapman & Hall, London, 996. pp [8] G. Berio, F.B. Vernadat, New developments in enterprise modelling using CIMOSA Computers in Industry, Elsevier, Amsterdam, Nov. 999, pp [9] D. Hollingsworth, The Workflow Reference Model, WfMC, Hampshire UK, Jan [0] Workflow Management Coalition. Interface : Process Definition Interchange Process Model, WfMC, Hampshire UK, Nov (Official Release 7.04) [] Workflow Management Coalition. Terminology and Glossary. Hampshire UK, WfMC, Feb [2] R.M. Bastos, J.P.M. Oliveira, F.M. Oliveira, Decentralised Resource Allocation Planning through Negotiation, In Camariha-Matos, L.M. et al. (Eds.) Intelligent Systems for Manufacturing: Multi-Agent Systems and Virtual Organization. Kluwer Academic Publishers, 998, pp [3] R.M. Bastos, J.P.M. Oliveira, F.M. Oliveira, Real-Time Resources Allocation Planning under a Market-Oriented Behaviour Perspective, In Proceedings of the 5th ISPE/IEE International Conference on CAD/CAM, Robotics & Factories of the Future CAR&FOF 99, Águas de Lindóia - Brasil, 999, pp. MW6-6 MW /0 $0.00 (c) 200 IEEE 0