Object model for initiating physical operations

A method to be performed in a process of a computer system initiating physical operations includes receiving, in a computer system, a request to generate a first object and a second object. The first object is to be used in initiating a manufacturing-type operation and the second object is to be used in initiating a warehouse-type operation. The method includes generating the first object and the second object in response to the request. The first and second objects are generated using an object model for physical operations. A computer system includes a first resource and a second resource, and an object generating module configured to generate the first and second objects.

TECHNICAL FIELD

The description relates to a model for objects that can be used in initiating physical operations.

BACKGROUND

There exists systems for computerized automation of operations and processes in industrial or other commercial enterprises. Examples of such existing systems are those available from SAP AG in Walldorf (Baden) Germany. Some of the existing systems are intended for use with the logistic procedures and operations that are common in manufacturing processes and they are therefore typically used in production plants. Other systems, or components of systems, are intended for use in the logistic management of products that have already been manufactured. They are therefore typically used in warehouses, distribution centers and other facilities where goods may be inspected, repacked and moved to particular storage locations while awaiting shipment.

The distribution of responsibilities and functionality between these two categories of systems is based on the way that these industries have emerged and developed historically. That is, over decades in the past, production plants and similar facilities have carried out their operations according to well-established routines that involve the basic steps of making the product. Improvements in technology have changed the way certain tasks are performed, but the general logistic view of how the core constituents of the manufacturing process is carried out has not changed as significantly. Similarly, warehouses have traditionally been viewed as facilities mainly for logistic management of goods without significant modification and, thus, essentially non-manufacturing in nature.

This view is reflected in the existing systems for controlling manufacturing processes. The computer model they use for the different components of the process are typically specialized and heavily flavored by the traditional manufacturing view. Systems for warehouse management, in contrast, have other computer models that are targeted toward managing the logistics of storing and eventually delivering goods. A disadvantage of existing systems, then, is that they are designed and configured for only their type of process and lack flexibility in adapting to new demands in the industry and the marketplace that challenge the traditional views.

SUMMARY

The invention relates to an object model for initiating physical operations.

In a first general aspect, a method to be performed in a process of a computer system initiating physical operations includes receiving, in a computer system, a request to generate a first object and a second object. The first object is to be used in initiating a manufacturing-type operation and the second object is to be used in initiating a warehouse-type operation. The method includes generating the first object and the second object in response to the request. The first and second objects are generated using an object model for physical operations.

Implementations may include any or all of the following features. The method may further include generating a step object for at least one of the first and second objects, the step object representing performance of a step in the associated operation. The method may further include aggregating the first and second objects into an operation object. The aggregation may be done by assembling the first and second objects under a hierarchy node in the object model. The hierarchy node may be selected from among several hierarchy nodes in the object model based on a type of the hierarchy node. The manufacturing-type operation may be designed to transform a material of a product, and the warehouse-type operation may be (1) designed to physically move a product, or (2) designed to physically pack the product. The method may further include defining an input for at least one of the first and second objects, the input specifying a condition for initiating the associated operation. The method may further include defining an output for at least one of the first and second objects, the output specifying a result of performing the associated operation. The method may further include initiating the manufacturing-type operation using the first object and initiating the warehouse-type operation using the second object. The method may further include generating an electronic view for at least one of the first and second objects, the electronic view being defined by the object model. The electronic view may represents a material flow regarding the manufacturing-type operation or the warehouse-type operation. The electronic view may represent a scheduling regarding the manufacturing-type operation or the warehouse-type operation. The electronic view may represent a description of the manufacturing-type operation or the warehouse-type operation.

In a second general aspect, a computer system includes a first resource and a second resource. The first resource is configured to perform a manufacturing-type operation with regard to a product. The second resource is configured to perform a warehouse-type operation with regard to the product. The computer system further includes an object generating module configured to generate a first object to be used in initiating the manufacturing-type operation and a second object to be used in initiating the warehouse-type operation. The first and second objects are generated using an object model for physical operations.

Implementations may include any or all of the following features. The object generating module may further be configured to generate a step object for at least one of the first and second objects, the step object representing performance of a step in the associated operation. The object generating module may further be configured to generate an electronic view for at least one of the first and second objects, the electronic view being defined by the object model. The electronic view may represent a material flow regarding the manufacturing-type operation or the warehouse-type operation. The electronic view may represent a scheduling regarding the manufacturing-type operation or the warehouse-type operation. The electronic view may represent a description of the manufacturing-type operation or the warehouse-type operation.

DETAILED DESCRIPTION

FIG. 1shows an activity object100for computer-planned and initiated operations. An activity object100may be used for processes that include, but are not limited to, operations to move, make, maintain, check and pack products or other items. These operations can be performed in various locations where, for example, products are produced and services are performed, such as manufacturing plants and warehouses.

One or more activities102are defined for the operation. The activity102contains the information needed to perform an action in the execution of an operation. Examples of activities include, but are not limited to, setup, produce and pack.

The activity102may have certain requirements in order to perform its action in the execution of an operation. Such a requirement depends on the operation to be performed as well as the type of process to be executed. For example, the activity102may involve taking a required material needed in the manufacture of a product from a bin or to move a completed product from the assembly line to the packaging line. In these examples, it is required that the material or the product are in their respective locations before the activity is performed.

An input104is therefore defined as a pre-condition for the activity102. Included with the input104may be information needed by the activity102in order to use the input104in its process, for example any of the categories just mentioned.

An output106is defined as a result of the activity102. As in the example above, the output of the move activity is the placement of the completed product on the packaging line.

The activity102may be associated with relations to other activities. An input activity relation108is a description of a sequence in which the activity102is performed. An output activity relation110is a description of a sequence that can be used as an input activity relation for the next activity. The input activity relation108indicates the link from a previous activity to the activity102. Similarly, the output activity relation110indicates the link from the activity102to a subsequent activity. The input activity relation108and the output activity relation110allow for relational information to be passed from one activity to another enabling their connectivity. For example, the input activity relation108may define that the activity102can be initiated immediately upon finishing the previous activity, or that there must be a predefined cooling period between finishing the previous activity and beginning the activity102.

FIGS. 2A and 2Bshow examples of activity objects that can be used for specific operations. First,FIG. 2Ais an example of a move activity that involves moving a material from a Location1to a Location2. A move activity object200includes an input202which is, in this example, a raw material at Location1. The activity for this operation is a move activity204. This activity includes moving the raw material from Location1to Location2using a forklift F1as a resource. The activity includes an output206that represents the raw material being present at Location2.

Second,FIG. 2Bis an example of a make activity that involves the mixing of two materials, Material A and Material B, to a new material, Material C. A make activity object208includes an input210of Material A and another input212of Material B. The activity for this operation is a make activity214. The action for this activity is the mixing of material A and material B using a machine M1as a resource. The make activity214includes an output216of Material C which is the result of mixing Material A and Material B.

FIG. 3Ashows a physical process300performed for an exemplary product order.FIG. 3Bshows a technical representation330of the physical process ofFIG. 3Athat uses execution objects in performing the operations.

The physical process300uses at least two different raw materials302stored in a component warehouse304. These raw materials302are to be used in the manufacturing of a product in a production facility306. The raw materials302are physically moved from the component warehouse304to the production location306using a resource308, for example a forklift. The raw materials302are placed at a raw materials receiving area310. From the raw materials receiving area310the raw materials are provided to a machine312used in the manufacture of the product. The machine312produces an intermediate product314using the raw materials302. The intermediate product314is used by a machine316that, in this example, produces a finished product318. The finished product318is then put through a Quality Management (QM) check320. If the finished product318fails the QM check320it can be discarded at this point or be sent back for additional processing. If the finished product318passes the QM check320, it is then considered an approved product322. The approved product322is then physically moved to a delivery zone324using a resource326, for example, a forklift. This move may be between areas within a physical plant or between separate plants. The approved product322is placed in a final product receiving area328where it may be placed in inventory for later shipment to a customer.

InFIG. 3B, the technical representation330uses hierarchical nodes (HN) as generic structuring elements within a framework. The framework consists of a building of hierarchy nodes that may have one or more activity objects associated with them. Particularly, the hierarchical nodes can be used with both production-type operations and warehouse-type operations. A hierarchy node header (HN HDR)332represents the product order.

A HN Move node334represents the moving of the raw materials302from the component warehouse304to the production facility306. An activity338is associated with the HN Move node334. The activity338takes inputs336, which are the two different raw materials302, and performs a move operation. This results in outputs340, which correspond to the two different raw materials302being placed into the raw material receiving area310. The move operation uses the resource308, which in the example is a forklift. A network342connects the HN Move node334to a HN make node344, which is the next execution node in the order process.

The HN Make node344represents the operation of the machine312. The node has two activity nodes associated with it. An activity346performs a make operation using an input348. The activity346corresponds to a first portion of the operation performed by the machine312. For example, the activity346is performed on the white material of the raw materials302. After the activity346there follows an input350into an activity351which corresponds to a second portion of the operation performed by the machine312. For example, the activity351involves adding the black material of the raw materials302to the processed white material. An activity relation352indicates that the activity346is performed before the activity351. The activity351performs a make operation using the input350to produce an output354, which represents the intermediate product314. An HN Make node356represents the operation performed by the machine316. The HN make node356and the HN Make node344together represent the physical manufacturing process for the product as shown by the network358.

The HN Make node356has associated with it two activity objects. An activity360is a setup operation, for example to set up the machine316. An activity relation362indicates that the activity360is performed before an activity364. The activity364is a make operation using input366, which is the intermediate product314and resulting in output368, which is the finished product318. A network370shows that a HN QM node372is the next execution node in the order process.

The HN QM node372represents the QM check320of the physical process. The node has associated with it an activity374to perform a check operation on an input376, which is the finished product318, and to produce an output378, which is the approved product322. A network380shows that a HN Move node382is the next execution node in the order process.

The HN Move node382represents the movement of the approved product322from the production location306to the delivery zone324. The node has associated with it an activity384to place the approved product322in a specific location. It does this by performing a move operation using a resource326. An input386is the approved product322in the production location306and an output388is the approved product in the delivery zone324.

FIG. 4shows an exemplary architecture that can use common execution objects and that is here referred to as a Unified Execution Order (UEO)400. The UEO architecture has three layers: a UEO application layer402, a UEO foundation layer404, and a UEO runtime layer406. These layers provide a framework for order-like applications in the logistics area, especially site logistics (SL), for example a warehouse, and production (P), for example a manufacturing plant.

The UEO application layer402includes one or more production orders, here P-Order405, one or more production lots, here P-Lot408, one or more site logistic orders, here SL-Order410and one or more site logistic lots, here SL-Lot412. An order is an object that is used to model and describe a process down to the execution level. The order also defines one or more resources to be used in performing the process. A lot is an object that is used to execute a process. The lot collects data for the process and may document its progress.

Abstract interfaces and nodes as well as several controller-like objects together form the UEO runtime layer406. The UEO runtime layer406may also include relations, actions and queries. Here, the UEO runtime layer406also includes Advanced Business Application Programming/Object Oriented interfaces (ABAP/OO interfaces) which is a coding that may be used for implementing business logic within the UEO framework.

The UEO runtime layer406provides a generic basis for various standard building blocks, which are UEO nodes and UEO actions that are present in the UEO foundation layer404. Based on the runtime there are several specific nodes classes provided. Examples of common reusable UEO nodes include operations that provide a process description.

Here, the UEO foundation layer404includes operation MAKE414where, for example, a product is fabricated from input raw materials. The layer404also includes operation MOVE416where, for example, a raw material is moved from a warehouse to a production location and operation PACK418where, for example, a product is placed in a box for shipment to a customer. Other example common reusable UEO nodes may be used to model and control material flow. Examples of these are I/O node420and quantity flow422. Another example involves scheduling data using a scheduling element424. Another common reusable UEO node may be an activity with steps426which may be a step-by-step description of how to perform a particular activity. Different UEO applications can use any or all of the example node types, as well as others.

The node types are not limited to use by the specific applications mentioned here but can be reused in other applications. As simple building blocks, the common reusable UEO nodes can be combined with application specific requirements and application specific logic to perform the necessary application processes. This can help to unify the implementation of application components.

The additional specific UEO nodes and application structure is shown in the UEO applications layer402. The structure may include, but is not limited to, the four applications shown. The P-Order405and P-Lot408applications may be used in the production of a product, for example. The P-Order405can contain the execution instructions for the manufacture of a product. The product order object is extensible in a way that each application can provide additional application specific node types. This is shown, for example, by the introduction in the P-Order405of node type step428and node type reporting point430, being used only by the P-Order405together with UEO foundation layer404node types. The introduction of application specific node types can be done in each application, if desired.

The P-Lot408collects the information about the execution of the activities of the P-Order405. This information can be used, for example, to confirm production steps, or in inventory management or for cost calculations. For example, the P-Lot can show that an activity that was planned to be performed once had to be performed twice before the desired outcome was achieved.

FIG. 5shows an overview of an exemplary object structure500. The structure500shows how a production order or a site logistics order can be modeled using nodes, shown as boxes in the figure, and relations, shown as connecting lines in the figure. The nodes may be included in the UEO application layer402or in the UEO foundation layer404, and the relations may be contained in the UEO runtime layer406.

The exemplary production order includes five nodes types, three of which are application specific. One of the application specific node types is a header502which contains a process description node504. This node, for example, contains the data needed to manufacture the product. The reporting point node type506is another application specific node type where process progress is reported. The reporting point node type506includes quantity nodes which can be an end quantity node508or a start quantity node510. The third application specific node type is a step512which can define a specific action needed in the manufacturing process. These node types may be included in the P-Order405and in the P-Lot408, for example. The application-specific nodes may include parts that are covered by the general object model.

The exemplary production order also uses two common reusable UEO node types: the operation node type514and the activity node type516. The operation node type514contains one or more operation nodes518such as operation MOVE416or operation PACK418as described above. The operation node type514contains one or more activity nodes520such as an activity with steps426as described above.

Material flow nodes522are assigned to the operation node type514of the process description504and represent the movement of materials from one operation node518to another. In the case of a production order as in this example, the material flow nodes are transformation nodes assigned to an operation. They represent the intermediate product stages of the manufacturing process. Quantity nodes are assigned to a reporting point node type506where the quantity of the manufactured product at its current state can be reported. The start quantity node510may be the input to an operation node518which is part of a work-in-progress (WIP). The end quantity node508may represent the product quantity between WIP operations. The end quantity node524may represent the final product quantity from the manufacturing process. These nodes may be included in the UEO foundation level404and can be used by production orders and by site logistic orders, to name two examples. For example, the material flow nodes522can be used in generating a view of the process to a user. The view may include material flow information and can be output on a display device.

The scheduling control526is assigned to the activity level516. The scheduling control nodes are used, for example in a production order, for adding date and time information to the order. This information may be used to schedule an activity or to coordinate the sequencing in time between two activities. These nodes are also part of the UEO foundation level404and are reusable by other UEO applications. For example, the scheduling control526can be used in generating a view of the process to a user. The view may include scheduling information and can be output on a display device.

FIG. 6is an overview-level process flow chart600. These operations are separated into three areas: an enterprise service framework (ESF) service602, a UEO application604and a data buffer (DB)606. The ESF service602provides a generated service608associated with a service provider. This generated service608is the entry point to the UEO application604. The UEO application604provides business object (BO) independent node types, relation types, actions and queries allowing it to run underneath different business objects within the ESF service602. A production order or a site logistics order are examples of business objects. The UEO application604, therefore, introduces a mapping between the entities of the business objects within the ESF service602and the UEO application604.

One UEO BO controller instance610is provided to the ESF service602from the UEO application604. This UEO BO controller instance610is related to one registered UEO application, for example a production order. The service provider dispatches all calls it receives from the ESF service602to the UEO BO controller instance610. The UEO application604also provides to the ESF service602a UEO BO access adapter class612for each implementation of a given UEO interface. These UEO application-specific adapter classes are responsible for mapping BO-specific global data types and the names of BO nodes, relations, actions and queries to a corresponding UEO instance.

One UEO BO access adapter class612is allowed to access multiple UEO nodes616or UEO items618depending on the specific ESF request and the application-specific UEO node model, examples of which were described inFIG. 5. On top of UEO items618the UEO application604allows the instantiation and execution of a UEO action620. Examples of UEO actions are semantic checks or re-calculations along the material flow path, an example of which was shown inFIG. 5. The UEO action620is associated with a UEO node621which in this example is structured by three UEO items618. The UEO application604also allows the instantiation and execution of a UEO query622. The result of the execution of the UEO query622may be a table of globally unique identifiers and a node type, for example as described inFIG. 5.

The lifecycle of the UEO node616is controlled by a UEO controller624whose classes are implemented together with the UEO node classes. The UEO application604at runtime can access the registered UEO controllers using code that may be customer-specific, for example using a filter-based Business Add-In Builder as available in products from SAP AG in Walldorf (Baden), Germany.

The UEO nodes616and UEO items618are central instances that belong to different classes. They behave like persistent instances in terms of the used persistency control service APT (Agent, Persistent, and Transaction). Each persistent class is related to one stateless agent class that uses an APT Agent626to map the persistent instance attributes of the UEO node616to corresponding database table fields628within the DB606. This may be done without a global data buffer based on internal tables. The node instances themselves are building the transactional buffer and an APT transaction630controls the transactional state of the DB606.

Each controller behaves like a UEO controller624by implementing one given interface in order to provide access to specific UEO node instances. The controller also behaves like an APT controller in order to handle nodes as persistent instances that are collected in one controller-related APT collection630.

The above described process flow may be implemented based on object oriented interfaces to implement the business logic needed within the UEO framework, for example using the ABAP programming language. The UEO nodes and optional UEO node items may be central instances in the interface.

FIG. 7shows an example of a complete production order800. Each of the entities in the production order800may be a UEO node defined in either the UEO foundation layer404or the UEO application layer402as described inFIG. 4. The relations between the UEO nodes are defined by the production order and may be managed by the UEO at runtime, as shown inFIG. 6.

The production order header node802contains the data needed by the production order as well as the process description. In the production order hierarchy, many operations can be associated with the production order header node802. In this example there is a first node804for a first operation and a second node806for a second operation which can be of any of the types previously defined. Also associated with the production order header node802are reporting point nodes. This example has two reporting point nodes, RP808and RP810. Next in the production order hierarchy, below operations, are activity nodes. This example shows four activity nodes812,814,816and818. Examples of the header node, the operation nodes, the reporting point nodes and the activity nodes were described inFIG. 5. The production order header node802, the reporting point nodes, the operation nodes and the activity nodes all belong to the hierarchy class for the production order.

Another class in the production order is the scheduling class which contains scheduling element nodes, in this example, nodes820,822,824and826. In this example, a scheduling element node is assigned to each activity node and is used for adding scheduling information to order entities (or groups of entities). It describes a time interval according to its start and end timestamps. Each scheduling element node has associated with it one or more resource requirements, for example resource requirement node828. The resource requirement node828denotes a capacity requirement on a certain resource and refers to a scheduling element node, in this example scheduling element node822.

The scheduling element node822also has associated with it an input node830that stores time information and represents the time stamp element used in scheduling control by the scheduling element node822. A scheduling relation node832connects two scheduling elements, denoted as a source scheduling element820and a target scheduling element822. The type of the scheduling relation can have the values ES (end-start), SS (start-start) or EE (end-end). The scheduling element node826has associated with it a resource requirement node834and an output node836. The output node836stores time information and represents the time stamp element result of the scheduling control used by the scheduling element node826. The resource requirements, the scheduling elements, the scheduling relations and the input node830and the output node836are all in the scheduling node class. A link may be provided between this class and the hierarchy class. For example, a link can be provided between a scheduling element and an activity. This link would provide scheduling information to the activity to ensure the resources and raw materials needed for that activity be made available prior to the start of the activity. An example of this is a link838between activity node812and scheduling element node820.

The material flow class consists of input nodes, transformation nodes, quantity nodes and output nodes. An input node840represents materials and handling units entering the processing of an order. A handling unit is a physical item consisting of packaging materials and the products they contain. A transformation node842describes the transformation of several input or quantity nodes into several other output or quantity nodes. The transformation node842specifies proportions between the ingoing and outgoing quantities. For example, in production the standard rule is that all ingoing and outgoing quantities are proportional to the master output of the order.

A quantity node844is both an output of a previous step, in this example transformation node842, and an input of a proceeding step, in this example transformation node846. It models intermediate materials and handling units that stay in the process. It also represents the reporting point quantity, as shown by a link848between the quantity node844and the reporting point node808. For example, at the reporting point all material quantities are captured and reported to the production order header node802. A quantity node is used in the intermediate places in the material flow where items are counted. As an example, “in-transit” stock is modeled with a quantity node. A quantity node may also be used at the end of the production order process to count finished goods and deliver them as the order output. This is shown by a quantity node850associated with an output node852linked to the reporting point node810by link854. The reporting point node810then reports the results to the production order header node802.

Linking a transformation node to an operation is another way of linking the material flow class and the hierarchy class. For example, operation node804can be linked to the transformation node842by link856. The operation node can provide the operation needed by the process used to perform the product transformation within the transformation node842.

The material flow class can also be linked to the scheduling class. For example, the input840can be linked to the input830by link858. This can provide timestamp information about the availability of the input840. The output852can be linked to the output836by link860to provide timestamp information about the availability of the output product.

FIG. 8is a block diagram of a computer system900that can be used in the operations described above, according to one embodiment.

The system900includes a processor910, a memory920, a storage device930, and an input/output device940. Each of the components910,920,930, and940are interconnected using a system bus950. The processor910is capable of processing instructions for execution within the system900. In one embodiment, the processor910is a single-threaded processor. In another embodiment, the processor910is a multi-threaded processor. The processor910is capable of processing instructions stored in the memory920or on the storage device930to display graphical information for a user interface on the input/output device940.

The memory920stores information within the system900. In one embodiment, the memory920is a computer-readable medium. In one embodiment, the memory920is a volatile memory unit. In another embodiment, the memory920is a non-volatile memory unit.

The storage device930is capable of providing mass storage for the system900. In one embodiment, the storage device930is a computer-readable medium. In various different embodiments, the storage device930may be a floppy disk device, a hard disk device, an optical disk device, or a tape device.

The input/output device940provides input/output operations for the system900. In one embodiment, the input/output device940includes a keyboard and/or pointing device. In one embodiment, the input/output device940includes a display unit for displaying graphical user interfaces.

To provide for interaction with a user, the invention can be implemented on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer.