Patent Application
20150317575
This invention relates to modeling workflow and/or production pipelines, and more particularly to a method and apparatus for modeling a production pipeline based on the assets required and produced along the production pipeline.
For any movie, television, or record production, there are several assets such, a shots, visual effects, sound, etc that are in several different formats are that transferred between different productions companies which may produce new assets in new formats. These assets are the building blocks used to make a television show, movie, record, or the like. Keeping track of such assets and knowing what the location and state of the assets is a tremendously complicated endeavor.
Project manager programs exist but they are typically designed for a top down static system design where each block representing a stage of the project is associated to the next block by the user to create the system. Blocks do not link together based on assets nor do the programs track such assets.
Thus, a method and system that can model a workflow and/or a production pipeline based on assets used in the production of a movie, television, music album, etc. is needed.
Asset-driven workflow dependency management establishes connections between activities based on the descriptions of the assets used as inputs and/or outputs for each activity. These descriptive “contracts” provide a mechanism to readily match relevant activities necessary to create a desired output. By creating a graphical model of desired workflow a user is provided with a better understanding of what is involved in the workflow as well as where issues and redundancies may occur. The graphical model can be used to design and track real world productions.
Graphical representations of activities are used to model venders, facilities and other production activities. The activity models produce and/or consume assets that represent the deliverables that are transferred between activities. Using the models of activities, a model of the production pipeline can be built from back to front. Thus, a final result activity model is selected first and based on the assets required by the selected final result activity an appropriate activity that produces that required asset can be selected. This process can be repeated until the beginning of a process pipeline is reached. A real world process pipeline can then be formed based on the model and the model can be used to track the status of the real world production pipeline.
One embodiment of the disclosure provides a method for modeling a workflow. The method includes the steps of providing a graphical representation of a first activity having at least a first input with an associated asset descriptor, providing a graphical representation of a second activity having at least an output with an associated asset descriptor matching the asset descriptor associated with the first input of the graphical representation of the first activity, and connecting the first input of the graphical representation of the first activity with the output of the graphical representation of the second activity based on the matching asset descriptors.
Another embodiment of the disclosure provides an apparatus for modeling a workflow. The apparatus includes storage, memory and a processor. The storage and memory are for storing data. The processor is configured to provide a graphical representation of a first activity having at least a first input with an associated asset descriptor, provide a graphical representation of a second activity having at least an output with an associated asset descriptor matching the asset descriptor of the at first input of the graphical representation of the first activity, and connect the first input of the graphical representation of the first activity with the output of the graphical representation of the second activity based on the matching asset descriptors.
Objects and advantages will be realized and attained by means of the elements and couplings particularly pointed out in the claims. It is important to note that the embodiments disclosed are only examples of the many advantageous uses of the innovative teachings herein. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention, as claimed. Moreover, some statements may apply to some inventive features but not to others. In general, unless otherwise indicated, singular elements may be in plural and vice versa with no loss of generality. In the drawings, like numerals refer to like parts through several views.
Turning now to
The processor 210 controls the operation of the server 200 or electronic device. The processor 210 runs the software that operates the server or electronic device as well as provides the functionality of the asset driven workflow modeling application. The processor 210 is connected to memory 220, storage 230, and network interface 240, and handles the transfer and processing of information between these elements. The processor 210 can be general processor or a processor dedicated for a specific functionality. In certain embodiments there can be multiple processors.
The memory 220 is where the instructions and data to be executed by the processor are stored. The memory 220 can include volatile memory (RAM), non-volatile memory (EEPROM), or other suitable media.
The storage 230 is where the data used and produced by the processor in executing the cold storage recommendation methodology of the present disclosure is stored. The storage may be magnetic media (hard drive), optical media (CD/DVD-Rom), or flash based storage. Other types of suitable storage will be apparent to one skilled in the art given the benefit of this disclosure.
The network interface 240 handles the communication of the server 200 or electronic device with other devices over a network. Examples of suitable networks include Ethernet networks, Wi-Fi enabled networks, cellular networks, and the like. Other types of suitable networks will be apparent to one skilled in the art given the benefit of the present disclosure.
It should be understood that the elements set forth in
Pipeline: A collection of Activities connected together to create a desired output. The pipeline provides a graphical model of the workflow. For example of video or film production, the pipeline represents all the activities (such as generation of data, specific shots, formats, or audio tracks) necessary to produce the desired product.
Activity: An operation that produces, transforms, or consumes Assets (Including deliverables such as data, specific shots, formats, or audio tracks). Each Activity may have inputs, an output or both. As a simplifying assumption, activities typically only have a single output (although the output could be a complex or compound asset). Activities (except for consuming activities) can be easily characterized by their output. What makes an Activity unique is the specific configuration of inputs that are mapped via the Activity to produce a given output. Different Activities may create an identical output and therefore only one would be required within a given Pipeline. The output of a given activity can provide input into multiple downstream Activities.
Connection: when an Activity output description matches one or more input descriptions then a Connection is implied. Connections represent fulfillment agreements or contracts for the delivery and receipt of Assets.
Asset Descriptor: The label of an input/output of and Activity used for matching and establishing connections between Activities.
Further discussion of these concepts is provided later in this document.
Step 410, as shown in graphical example 500 of
In step 420 of the graphical example 500 of
Selecting the desired second activity, in this case activity 520, into the pipeline implies a connection between the activities 510, 520 since the asset descriptor associated with the output of the second activity 520 matches the asset descriptor of the input 512 of the first activity 510. The implied connection is represented in step 430 as a graphical connection 540.
In this embodiment, the matching and connection is based on asset descriptors not the asset itself. This allows for the creation of a complete pipeline model before actual assets exist. Some benefits of such asset driven modeling include: explicit mapping of activities based on the descriptions of assets they output or consume, provenance of assets can be traced explicitly through the system, and downstream dependencies can be easily calculated.
In the world of media production it is common to encounter activities which produce a number of like elements as part of larger set. For example a “Dailies” activity is responsible for converting video and audio “shots” captured on-set into an easily reviewable format for the director or producer to review and approve.
As an example: the Dailies activity might be responsible to process 1000 “shots” over a period of a few weeks. Furthermore these “shots” may come from different camera units in a non-sequential fashion. The output of the “Dailies” activity is regularly passed through to the next step on a daily basis.
For the modeling of such a system, the use of sets may be beneficial. Set are collections of one or more assets that are of the same type. Each member of the set is a unique asset but is of the same type or class as the other assets in the set. For example, a set may consist of 500 shots but each member of the set is a shot. Sets can be used to distribute and accumulate work product across multiple activities. Sets can also be divided into sub-sets as well. Hence, an activity might receive different sub-sets from different activities or an activity might only consume a portion of the original produced.
The methodology of modeling a workflow using sets is similar to the methodology for non-set asset driven modeling as set forth in
In the workflow model 600 of
In the embodiment of
As set forth previously, the second activity 620 in the model 600 of
Graphical representations of a fifth activity 650 and sixth activity 660 are also provided in the model 600 of
As can be seen, asset descriptors are used to model inputs and outputs to create connections between activities and identify potential activity connections. In certain embodiments the asset descriptors can be used to correlate with existing assets in an asset registry.
In certain embodiments asset descriptors can be used for exact or parameterized matching, where parameterized matching provides some wildcard-like capabilities when descriptors are compared. In the present examples, a fully defined asset descriptor is denoted with a capital letter in a circle, for example:
A parameterized asset descriptor can be denoted with a capital letter “primed” in a circle. For example:
Activity Instance. Is an activity where all input and output asset descriptors are fully defined, meaning there are no undefined parameters.
Activity Template. Is an activity having one or more parameterized asset descriptor to facilitate reuse. This, however, is not a requirement.
Activities are defined in terms of their inputs and outputs. Inputs and outputs are defined, in-turn, by their asset descriptors. The specific combination of inputs and outputs determines the “signature” of the activity (regardless of what it might be named). In the example of
To model a connection between activity instances the output of an upstream activity needs to match the input of a downstream activity. Multiple downstream activities may consume the same asset. In the first model 800 of
To model a potential connection between an Activity Instance with an Activity Template the Input of the instance can do a template match with the output of the template (or vice-versa). An example of this can be seen in model 900 of
Using single letters up to this point was one approach to illustrate the disclosed concepts at a high level. In practice there are an arbitrarily large number of ways to describe an asset. One embodiment uses a collection of name/value pairs in order to provide a human readable and flexible mechanism for creating Asset Descriptors. An Asset Descriptor can be comprised of one or more name/value pairs taken as a whole to describe the asset General Asset Descriptor format:
A parameterized description simply leaves one or more values blank. In the example below both “Title” and “Version” are parameters.
Asset Identifiers are normalized versions of the Asset Descriptor. First the Asset Descriptor is normalized so case and name/value pair order do not affect the comparison. To normalize the Asset Descriptor, names and values are forced to lower case (optional) then sorted by name and the result concatenated.
The Asset Descriptor:
Optionally a cryptographic hash can be performed on the above result to create a unique numeric (hex) identifier shown below:
147c21 df6e470da7879307dbfb2e2a5d3e9c40719ba2a1a840bf71c732f71b2f
The cryptographic hash variant of the Asset Identifier is especially useful when identifying user interface elements as a class or id parameter in HTML where the textual version has too many issues to be convenient.
An Asset Reference concatenates the values in the order defined in the original Asset Descriptor separated by an underscore “_” character. This provides a human readable shorthand to less formally describe the asset.
The above example becomes:
‘The Hobbit_Trailer_Netflix Encoding’
Asset Descriptors and Asset Identifiers can both be used for full identification. The Asset Reference, however, is for display convenience only and should not be relied on for unambiguous referencing.
Exact matching of fully-defined Asset Descriptors can be performed directly using the Asset Identifiers.
When matching a fully-defined Asset Descriptor with a parameterized descriptor the following rules are used:
Examples are shown the exemplary table 1000 of
When building a pipeline of activities it should be sufficient to select the desired output (consuming activity), fill in the desired parameter values and then allow the desired values to propagate as activities are identified to complete the pipeline. The example of
Step 1.0 (1110) of
In step 2.0 (1120) the specified parameters passed through connection 1114 are used to specify parameters for the asset descriptors (“B′” and “C″”) associated with the inputs of the provided second Activity Template 1122 making the Activity Template an Activity Instance. In this example the parameter of language for asset descriptor “C′” was not passed through because it was already specified.
In step 3.0 (1130) of
In step 4.0 (1140) specified parameters from the second Activity Instance are passed through connection 1126 to a provided forth Activity Template 1142. The passed specified parameters are used to specify parameters for the asset descriptor “B′” associated with the output of the provided forth Activity Template 1142 making the Activity Template an Activity Instance.
In modeling actual content creation and distribution pipelines the following heuristics can prove useful:
As the activities and assets of the graphical models discussed herein can often represent real activities or assets it can be beneficial to provide and maintain an Asset Registry. The Asset Registry maps Asset Descriptors (or Asset Identifiers) to the location of actual assets. By registering existing assets against fully defined Asset Descriptors it is possible to eliminate unnecessary activities from the pipeline upon definition.
As a modification to the previously defined pipeline building strategy a step to check the registry can proceed any attempt to match Activity Templates. It is possible to have multiple copies of an asset at different locations mapped to a given Asset Descriptor/Identifier.
In the modeling methodology described herein, activities and their connections are modeled based on asset dependencies (see Asset Descriptors section for details). Each connection between activities represents a logical dependency of the output of one activity to the input of the subsequent activity. In order to trace progress from activity to activity, connections can have a fulfillment status. An exemplary methodology for modeling fulfillment status in a workflow model can be seen in the flowchart 1200 of
At its simplest, the method involves two steps. The first step (1210) is providing a model of a workflow having at least a graphical representation of a first activity and a graphical representation of a second activity wherein the activities are connected based on matching asset descriptors. The second step (1220) is determining the status of at least one asset indicated by the matching asset descriptors that are the basis of at least the connection between the graphical representations of the first and second activities. The steps are described in more detail below in reference to
In the diagram 1300 of
The fulfillment status reflects the state of a physical/electronic asset moving from one activity to the next. When an activity has produced the expected output (asset) it is physically/electronically sent to dependent downstream activities so the process can continue. The fulfillment mechanism tracks the state of the asset movement (e.g. pending, sending, received, error). In certain embodiments the fulfillment status can graphically displayed or otherwise indicated as part of the graphical representation of the activities or other elements of the model.
In certain other embodiments, the status of an activity can be determined based on the fulfillment status of the assets being produced and/or consumed by activity. In certain further embodiments the status of the activity can be graphically displayed or otherwise indicated as part of the graphical representation of the activity or other elements of the model.
In certain embodiments, a single physical/electronic delivery can be leveraged by multiple downstream activities and multiple fulfillment records would be redundant. To solve this, a change can be made from an activity-to-activity dependency relationship to an activity-to-facility relationship. An example of this can be seen in
In the exemplary diagram 1400 of
The term “facility” has been chosen to differentiate from other “location” references used in the system. In addition the specific asset dependency relationship must still be maintained such that the fulfillment is dependent on not only the facility but also the specific asset that is to be delivered. In such embodiments, a fulfillment status now represents the delivery of a specific asset from a source activity to a facility which, in-turn, may be shared by multiple destination activities. A diagram 1500 of the interaction of these elements can be seen in
In the diagram 1500 of
A fulfillment status can be referenced for each pair of activities that share an asset description. When generating the fulfillment status the destination activity's vendor.facility descriptor can be used to determine if a fulfillment has already been created—if so, then the existing fulfillment record can be referenced, otherwise a new fulfillment can be created. In certain embodiments, reverse domain name syntax can be use for the facility descriptor so it's human readable (e.g. technicolor.perivale, technicolor.perivale.transcodingDept). Unique facilities warrant separate fulfillments but there can be multiple “facilities” at the same physical location. This will result in separate records to track fulfillment status independently.
Mapping Process Information onto Asset Data
The workflow modeling, up to this point, has been focused on driving asset creation processes (activities) consistent with the modeled pipeline. That is to say that the system dictated, based on the defined model, what activities depend on what and enforced registration of assets according to the Asset Descriptor scheme. An alternate approach is now provided for delivering a similar level of pipeline information but in a passive manner without direct influence of the underlying activities. The general idea is to overlay a pipeline model (process data) over asset data in order to derive status of the overall process.
When assets are created it is assumed that they are registered in an asset registry system. This methodology would require additional structured data consistent with the concept of Asset Descriptors and Asset Registry described above. The name/values of the asset descriptors would need to be consistent (e.g. titles, language, aspect ratio, etc).
A process model, comprised of activities which in-turn reference Asset Descriptors, would be obtained (perhaps from a process registry) and used to view the data in the asset registry to derive pipeline status information. An example methodology can be seen in the flowchart 1600 of
At its simplest, the method involves two steps. The first step (1610) is determining that an asset required for a model of a workflow exists. The second step (1620) is providing a graphical representation of an activity that involves the existing asset. The steps are described in more detail below in reference to
The diagram 1700 of
It is in the asset registry 1710 that the first step (1610) of is performed. To determine if an asset exists the asset registry is queried. The asset registry is a collection, such as a database, of the assets that have been generated or previously exist. In this example it is assumed the asset registry contains only assets for a given workflow. However, it should be apparent to one skilled in the art that the asset registry could contain any number of registered assets including assets that are not part of the current workflow model. In the example of
In the Process Model 1720 of
With Inferred Status 1730, for each activity in the pipeline model the corresponding asset descriptor is queried from the asset registry. If an asset matching the descriptor is found then that activity is assumed to be complete. It is then possible to infer what activities should be in progress by seeing if the inputs to those activities are complete but the output of the current activity is not complete. An example of a status table can be seen at 1740.
Using this basic mechanism, data sets can be approached in a number of ways:
Pre-defined pipeline: In this scenario the specifics of a pipeline are known in advance (i.e. title, version, aspect ratio, etc are defined). This allows for direct mapping to assets in the asset registry. The benefit of this approach is that you can view the status of a pipeline that doesn't have any corresponding activities registered yet.
Infer from existing assets: The system can assume a known pipeline but only for assets that already exist in the registry. As an example, if a translation is received and registered for a specific title, version, language then the system would create an instance for the Acquire Translation activity with the given values then infer the remaining pipeline by matching the output to other activity inputs and in-turn matching the outputs of those activities to the inputs of subsequent activities. The process could happen in an upstream direction as well by matching any inputs of a found activity and following the path of inputs to outputs.
A feature of this method of overlaying process model over existing data is that you can try multiple pipelines as “viewing lenses” to see which pipeline variation matches best.
While the previous discussions have focused on creating a model of a workflow and monitoring the status, in certain embodiments it may be advantageous to provide an overview of the pipeline. As such, a user interface may be provided to not only provide a graphical model of the workflow but also provide a high-level perspective of the workflow process. Examples of such a user interface can be seen in
In accordance with certain embodiments, when the system of the present disclosure is launched, the user will be prompted for credentials and then presented with the producer's workspace as depicted in screen shot 1800 of
This panel is also available in the Executive workspace. In that case selecting an activity from the executive panel will display the pipeline relative to activity selected.
In certain embodiments, a Revise action can be provided once an activity has been set to ready. Revising allows a user to see the impact of a change and then commit the change to be redone.
The information provided by these actions can be used to determine the fulfillment status of assets as well as the status of the activities themselves.
In the current display of the details view panel 1830, the actions, indicated by the highlighted “ACTIONS” tab are being displayed. If the “DETAILS” tab is selected, information about due dates and vendor information is displayed. If a date is set and the date is missed (e.g. not done by the due date) the system will flag that as an issue.
Another possible workspace is the Manager Workspace as depicted in screen shot 2200 of
The manager panel 2210 presents all work going through a specific activity. The manager panel 2210 allows a user to select a specific activity using field 2220. The work or tasks associated with the selected activity is then displayed in the panel 2210. Filters 2230 can be used adjust what is being displayed. The default filter only shows things that need working on, but filters can be set to show what's coming and what's already been completed. Once the work is done “Set to Ready” 2240 can be selected and the tasks drop off the board (unless the filters are set otherwise). The activity detail panel 1830 of the manger workspace 2200 operates as described in reference to
Another possible workspace is the Data I/O Workspace as depicted in screen shot 2300 of
The data I/O panel 2310 is designed to show all the actions related to a specific facility. It is primarily designed to show send and receive actions to accommodate the idea that people moving assets in and out of a facility may be different from those performing the work creating or modifying assets. The data I/O panel 2310 allows a user to select a specific activity using field 2320. The work or tasks associated with the selected activity, as well as their status 2340, is then displayed in the panel 2310. Filters 2330 can be used adjust what is being displayed. The default filter only shows things that need working on, but filters can be set to show what's coming and what's already been completed. Action such as “Set to Ready”, “Send”, and “Receive” 2350 can be selected and the status 2340 is updated accordingly. The activity detail panel 1830 of the data I/O workspace 2300 operates as described in reference to
Another possible workspace is the Executive Workspace as depicted in screen shot 2400 of
The executive panel 2410 provides overview data such a graphs and task lists. Filters 2420 can be used adjust what is being displayed. In this example, the top box determines what to filter on and the lower box sets the value to use. Results can be grouped using selector 2430. Selecting grouping headers 2440 allows for the groups to be expanded or collapsed. Selecting an item in the panel 2450 caused the related activities and tasks to be displayed in the filtered pipeline panel 1820 and the activity detail panel 1830.
The filtered pipeline panel 1820 of the executive workspace 2200 operates ad describe in reference to
The final exemplary workspace is the Pipeline Builder as depicted in the screenshot 2500 of
The template list 2510 provides a field 2512 for selecting a project or workflow. The relevant activity templates for the selected project or workflow are then provided in the template list. These results can further be filtered using the filter functionality 2514. If necessary a new template can be created using a creation tool 2516.
The workspace 2520 provided the functionality for building a pipeline model as discussed throughout this disclosure. In this embodiment, selecting an input or output of a graphical representation of an activity 2530 causes the result in the template list 2510 to be filtered based on the asset descriptors associated with the input or output.
The various embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage unit or computer readable medium. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (“CPUs”), a memory, and input/output interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be either part of the microinstruction code or part of the application program, or any combination thereof, which may be executed by a CPU, whether or not such computer or processor is explicitly shown. In addition, various other peripheral units may be connected to the computer platform such as an additional data storage unit and a printing unit.
All examples and conditional language recited herein are intended for educational purposes to aid the reader in understanding the principles of the embodiments and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and varies embodiments of the invention, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.
This application claims the benefit of U.S. Provisional Application Ser. No. 61/755,892 filed Jan. 23, 2013 and U.S. Provisional Application Ser. No. 61/833,770 filed Jun. 11, 2013 which are incorporated by reference herein in their entirety. This application is also related to the applications entitled: “SET HANDLING IN ASSET-DRIVEN WORFLOW MODELING”, “FULFILLMENT TRACKING IN ASSET-DRIVEN WORFLOW MODELING”, and “METHOD AND APPARATUS FOR MAPPING PROCESS INFORMATION ONTO ASSET DATA” which have been filed concurrently and are incorporated by reference herein in their entirety.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US13/77198 | 12/20/2013 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 61755892 | Jan 2013 | US | |
| 61833770 | Jun 2013 | US |
