Patent Application
20120203587
This application claims priority to EP Patent Application No. 11153858 filed Feb. 9, 2011. The contents of which is incorporated herein by reference in its entirety.
The disclosure relates to an integrated engineering and workflow system for engineering and executing workflows of mechatronic objects, and in particular to an active workflow support with mechatronic objects.
Management and controlling of tasks in product and project business is crucial for a successful design, production or implementation as well as operation, maintenance and service. Furthermore, management and controlling of tasks in product and project business is important for maintenance and service, modernization and, if necessary, scrapping of products as well as plants, i.e. during the whole lifecycle of products and plants. It is desirable for a product manager and other responsible persons in charge of the project to know at any time during a project, which may be conducted in and across any lifecycle phase of a product or plant, the realistic status in terms of timelines, quality, project progress and efforts as well as costs. This information should be available without too much effort for the responsible person. During project implementation, the necessary activities have to be executed by the involved project members correctly and efficiently which means that there has to be sufficient support for the daily work of the project members on a technical level. Usually, a project plan is defined where a project workflow system can be used in which the project plans are implemented as workflows which have to be executed during the project. In general, a workflow comprises some activities which are assigned to specific roles or directly to experts in the project and which are started automatically based on preconditions that have to be fulfilled. For example, a preceding activity has to be finished before the next activity starts. Each activity usually has a state such as “planned”, “in execution” or “finished” which can be interpreted by the workflow system during a project execution to indicate the current state of the whole workflow to a user. Before such a workflow activity is started, project experts or project members have to be assigned to the respective activities. The assigned project members are usually informed automatically about the start of the activity when all preconditions for this activity are fulfilled. The start of an activity can either be initiated automatically by the system or can be done manually by a user with appropriate rights. For example, at a project start, a project manager may initiate a first workflow activity manually. The responsible project experts or project members then execute the steps described by the activity and, when finished confirm the execution of the activity as a response to the system-initiated or manual start of the respective activity. As a result, the system can set a new state for this activity and can initiate further workflow activities or start new workflows, if necessary, i.e., if follow-up activities are modelled in the workflow system.
The active workflow elements do not only interact with a user and change their own state but can also change the state and content of other mechatronic objects or external data.
Although these conventional workflow systems already provide some support for project implementation, a conventional workflow definition is only based on generic mechanisms. Conventional workflow systems provide standard workflows which can be used directly in a project with few adaptations or allow defining completely new workflows and storing these workflows for reuse across projects. Other projects are only that similar on an abstract level. For example, project management tasks are usually very similar, however, e.g. how to commission a pumping station may depend on the specific devices used in this pumping station which can vary from project to project or which can depend on country-specific safety regulations which have to be obeyed and which have not been employed so far in former projects. In such a scenario, it would be beneficial for the project expert to get specific information about this hardware device directly from an assigned workflow activity. Since defining workflows and executing them in workflow systems causes some efforts, workflow support is usually employed only for highly repetitive tasks which are regulated by a company internally or by external standards or processes.
In conventional workflow systems activities are usually considered in a project workflow, only as far as they are important for later activities. These results are defined in the workflow, but there is in general only very limited connection between the workflow system and the systems in which the results are elaborated, e.g. the engineering systems. Accordingly, conventional workflow systems and concepts do support only very detailed project-specific workflow descriptions for project experts wherein a lot of effort for creating these workflows is necessary. Furthermore, such project-specific workflows are reusable across different projects only with very high efforts.
Furthermore, the conventional workflow systems are only poorly integrated with standard engineering systems used for the technical implementation of the project in which the real work is done. There are provided interfaces which can be used to integrate systems, however, this also requires a lot of preparation work before workflows can be executed in an integrated way.
This means in daily work, a lot of communication with colleagues is necessary for a project member in order to coordinate tasks that have to be done inside or during the activities, if more than one person or user is involved in the project.
In addition, project experts are not supported directly from the workflow with detailed information about the task they are expected to perform, but only on a rather abstract level. The used engineering systems are usually not integrated with the conventional workflow system. Therefore, a manual transfer of information between the workflow system and the engineering systems does not facilitate the daily work of the project experts.
Consequently, a complete project controlling and implementation with conventional workflow systems is not possible, since the workflow activities are still too far away from the daily tasks and provide less support, the more technical the activity gets. This often leads to the coexistence of more fine-granular and maybe discipline-specific workflows which are administered independently from the main workflow and which are often not supported by a system but are often pure instruction lists. This becomes in particular a problem, if persons which are not educated adequately or which do not possess exactly the necessary detailed knowledge required for some tasks which need more support. This scenario will happen even more in the future due to the trend of outsourcing and offshoring project execution as well as by the decreasing number of available project experts. This scenario causes also that workflow definitions are not stringent and not sufficiently detailed thus not supporting less experienced user adequately.
According to various embodiments, an integrated engineering and workflow system for engineering and executing workflows of mechatronic objects overcomes one or more drawbacks of conventional workflow systems.
According to an embodiment, an integrated engineering and workflow system for engineering and executing workflows of mechatronic objects is provided, wherein each mechatronic object comprises workflow data controlling an execution of at least one workflow within a life-cycle phase of a corresponding mechatronic entity.
According to a further embodiment, the workflow data comprises an executable workflow control program having a workflow control program code including instructions to perform automatically the respective workflow. According to a further embodiment, the workflow data comprises interpretable workflow configuration data which is interpreted by an interpreter to perform the respective workflow. According to a further embodiment, the mechatronic objects are data objects which are stored in a database of the integrated engineering and workflow system or which are stored in data memories of corresponding mechatronic entities connected to the integrated engineering and workflow system via a data network. According to a further embodiment, the workflow is an interactive workflow, and information data of the workflow is output to a user terminal and command data for the workflow is input by means of the user terminal. According to a further embodiment, the mechatronic objects have interfaces comprising parameter interfaces (PI) to exchange parameter data and message interfaces (MI) to exchange messages with each other via logical interface-connections and/or with a data processing unit of the integrated engineering and workflow system.
According to a further embodiment, the executable workflow control program is instantiated during an lifecycle phase of the respective mechatronic entity or during a runtime of the respective workflow. According to a further embodiment, at least one user terminal of a user is connected to the data processing unit of the integrated engineering and workflow system, wherein each user terminal comprises a graphical user interface having output means to output information data of the workflow to the user and input means to input commands for the workflow by the user.
According to a further embodiment, the output information data of the workflow comprises messages provided by mechatronic objects via message interfaces (MI) of the mechatronic objects to the user terminal, and the output information data indicates at least one action to be performed by the user during a workflow step of the respective workflow. According to a further embodiment, the input commands for the workflow comprise parameter settings for mechatronic entities and workflow instructions provided by the user terminal via parameter interfaces (PI) to mechatronic objects. According to a further embodiment, the life cycle phase of the mechatronic entity comprises an engineering phase, a commissioning phase, an operation phase, and a disposal phase of the mechatronic entity.
In another embodiment, a method for performing a workflow within a life cycle phase of a mechatronic entity is provided, wherein a corresponding mechatronic object of the mechatronic entity comprises workflow data controlling an execution of the respective workflow. According to a further embodiment, the workflow is formed by an interactive workflow, wherein information data of the workflow is output to a user terminal of a user and command data for the workflow is input into the user terminal by the user. According to a further embodiment, the workflow data comprises a workflow control program having workflow control program code which is executed to perform the respective workflow. According to a further embodiment, the workflow data comprises workflow configuration data which is interpreted by an interpreter to perform the respective workflow.
Example embodiments of an integrated engineering and workflow system for engineering an executed workflow of mechatronic objects and a corresponding method for performing a workflow within a lifecycle phase of a mechatronic object are described with reference to the figures, in which:
Some embodiments provide an integrated engineering and workflow system for engineering and executing workflows of mechantronic objects, wherein each mechatronic object comprises workflow data controlling an execution of at least one workflow within a lifecycle phase of a corresponding mechatronic entity.
Whereas a mechatronic entity ME refers to a physical mechatronic entity or unit a mechatronic object MO refers to mechatronic information which can represent a mechatronic entity ME in an engineering system. Mechatronic objects MO can also exist independently from mechatronic entities and can be used e.g. for organisational purposes. Mechatronic objects MOs can be stored in libraries or repositories for being reused. However, it is also possible that mechatronic objects MOs are generated during a project and are exclusively used for the respective project.
In certain embodiments, the workflow can be executed directly from a mechatronic structure itself without having the need to generate a workflow first. The integrated workflow system for engineering and executing of workflows of mechatronic objects enables an easy and effortless supplementation of a project workflow taking into account the technical activities which have to be performed. Integration of support on the one hand helps the experts responsible for the activities, but also decreases possible errors and thus enhances the quality of the project results. Since the necessary workflow information can be delivered immediately to the project experts, no time is lost for searching exactly this workflow information. The system further allows project managers and other users to watch a progress of the project in much more detail because they are provided with a real current state of the respective project.
In another example embodiment of an integrated engineering and workflow system for engineering and executing workflows of mechatronic objects, the workflow data comprises an executable workflow control program with a workflow control program code including instructions to perform the respective workflow. Accordingly, the steps of the workflow can be executed automatically. For example, version data can be generated and stored in a workflow.
In an example embodiment of an integrated engineering and workflow system, the workflow data can comprise interpretable workflow configuration data which is interpreted by an interpreter to perform the respective workflow.
In an example embodiment of an integrated engineering and workflow system, the mechatronic objects are data objects which are stored in a database of said integrated engineering and workflow system.
In a further example embodiment of an integrated engineering and workflow system, mechatronic objects are data objects which are stored in data memories of corresponding mechatronic entities connected to the integrated engineering and to the workflow system via a data network.
Workflow information or workflow data from the mechatronic objects form the program which can control the workflow for a technical system such as an assembly line.
In a further embodiment of the integrated engineering and workflow system, the workflow is an interactive workflow wherein information data of the workflow is output to a user terminal and wherein command data for said workflow is input by said user terminal.
In an example embodiment of an integrated engineering and workflow system, mechatronic objects have interfaces comprising parameter interfaces to exchange parameter data and message interfaces to exchange messages with each other via logical interface-connections and/or with a data processing unit of said integrated engineering and workflow system.
In an example embodiment of an integrated engineering and workflow system, the executable workflow control program is instantiated during an engineering phase of the respective mechatronic entity or during a runtime of the respective workflow.
Such a workflow control program can be started during any lifecycle of the mechatronic objects and can relate to each possible phase of the lifecycle.
In an example embodiment of an integrated engineering and workflow system, at least one user terminal of a user is connected to the data processing unit of said integrated engineering and workflow system.
In an example embodiment of an integrated engineering and workflow system, each user terminal comprises a graphical user interface having output means to output information data of the workflow to said user and input means to input commands for said workflow by said user.
In an example embodiment of an integrated engineering and workflow system, the output information data of the workflow comprises messages provided by mechatronic objects via message interfaces of the mechatronic objects to the user terminal.
In an example embodiment of an integrated engineering and workflow system the output information data can indicate at least one action to be performed by said user during a workflow step of the respective workflow.
In an example embodiment of an integrated engineering and workflow system, the input commands for said workflow comprise parameter settings for mechatronic entities and workflow instructions provided by said user terminal via parameter interfaces to mechatronic objects.
In an example embodiment of an integrated engineering and workflow system, the lifecycle phase of the mechatronic entity comprises one of a group of lifecycles comprising an engineering phase, a commissioning phase, an operation phase and a disposal phase, an update phase of the mechatronic entity or any other life cycle phase.
Some embodiments may provide a method for performing a workflow within a lifecycle phase of a mechatronic entity, wherein a corresponding mechatronic object of said mechatronic entity comprises workflow data controlling an execution of the respective workflow.
An example embodiment of a method, the workflow is formed by an interactive workflow wherein the information data of said workflow is output to a user terminal of a user and command data for the workflow is input into said user terminal by a user.
The command data can also be used, for example, to indicate necessary information for the work by means of other programs which are necessary for a decision. Other documents can be stored in a special file.
In an example embodiment of an integrated engineering and workflow system, the workflow data comprises a workflow control program having a workflow control program code executed by at least one processing unit to perform the respective workflow.
In another example embodiment of an integrated engineering and workflow system, the workflow data comprises workflow configuration data which is interpreted by an interpreter to perform the respective workflow.
As can be seen in
According to certain embodiments, workflow aspects, such as activities and status or resource information are included in mechatronic objects MO as additional information data. Accordingly, the mechatronic objects MO as employed by such embodiments may comprise the workflow aspect besides already existing aspects, such as mechanical or electrical engineering aspects. If mechatronic entities ME are put together or are assembled in a system, for example to build up a plant solution or a device or product, the workflow aspects of the corresponding mechatronic data objects MO are also integrated with each other. The integration of the mechatronic data objects MO can be performed either by the same system in which the mechatronic data objects of the corresponding mechatronic entities ME are put together, i.e. the engineering system or by a specialized system which provides the workflow functionality, but is integrated with the engineering system. This workflow system 3 supports the creation of a project workflow based on the workflow aspects provided by the different mechatronic objects MO as well as the workflow execution and workflow monitoring during project implementation.
Activities defined by mechatronic objects MO can be concatenated based on the structure of a mechantronic object tree and united in a superordinated activity attached to a superordinated mechatronic object. For example, activities of dependent mechatronic objects MO are serialized or activities of independent mechatronic objects MO are parallelized in the activity of a superordinated mechatronic object. Status and resource information can also be used by superordinated mechatronic objects in a mechatronic object tree to aggregate the information to the status and resource information of the superordinated mechatronic object MO. This means that a status and resource requirement of a mechatronic object MO can be calculated based on the status and resource information of the respective mechatronic object MO and its subordinated mechatronic objects. This can be either used for triggering activities or for getting an overview of the status of the whole project. During a project execution, the resource information can be used as resource requirements, for example the kind of expert or laboratory required for which number of working hours. The resource requirements can be fulfilled in order to execute the project. It is also possible to define a number of different statuses which are connected to a project phase.
After having generated a project flow created in a workflow system 3 as shown in
In a possible exemplary embodiment, the workflow system 3 can be split into two systems, i.e. a workflow definition and a workflow execution system. In an example embodiment, the workflow data of a mechatronic object 2-i as shown in
In an alternative implementation or embodiment, the workflow data of a mechatronic object 2-i can comprise interpretable workflow and configuration data which is interpreted by an interpreter to perform the respective workflow.
There can be variations in how workflow information is described. Further, there can be performed an active execution of the workflow aspects or an interpretation of the workflow aspects of the respective mechatronic objects. Both variations have a common procedure. During engineering of the mechatronic objects 2-i, the workflow aspects are created or instantiated, interconnected and parameterized. The complete mechatronic object can comprise at least one structured workflow aspect which is sufficient to define a workflow for the supported project phase such as a construction or commissioning phase. There can also be mechatronic objects which do not participate in the workflow.
A mechatronic object 2-i can support the workflow aspects for an arbitrary number of project phases. A workflow aspect controls e.g. the parameterization of a mechatronic object 2-i during engineering and another workflow aspect enables a consistency check during commissioning. It is also possible that a workflow aspect is assigned to a mechatronic object 2-i in general as well as that a workflow aspect is assigned to a specific facet or aspect of the mechatronic object 2-i. According to some embodiments, the integrated engineering workflow system tool can combine the engineering of the mechatronic object data structure and the control of the execution of the workflow of an assembly line of plant. Integrated engineering of a workflow system can still be used with different tools for both tasks, if different tools access the same database for the mechatronic objects or keeps the data otherwise in synchronization, for example by exchanging data with each other.
During engineering the engineering system can support the logical interconnection of mechatronic objects 2-i or the workflow aspects in order to shape the respective workflow. Its logical interconnection can be created in a possible implementation manually between aspects or the engineering or workflow system interprets the mechatronic object data structures and executes the workflow according to this data structure automatically.
As shown in the embodiment of
In a possible implementation, the executable workflow control program is instantiated during a lifecycle phase of the respective mechatronic entity 1-i. It is further possible, that the executable workflow control program is instantiated during a runtime of the respective workflow. At least one user terminal 6 of a user is connected to the data processing unit 5 of the integrated engineering workload system 3 as shown in
Output information of the workflow comprises messages provided by mechatronic objects 2-i via message interfaces of the respective mechatronic objects to the user terminal 6. Output information data can indicate at least one action to be performed by the user during a workflow step of the respective workflow.
Input commands input into the terminal 6 by the user can comprise parameter settings for mechatronic entities 2-i and workflow instructions provided by the user terminal 6 via parameter interfaces of mechatronic objects 2-i.
In an example embodiment, an active execution of the workflow aspect is performed. Active workflow aspects can contain code or definitions which can be executed directly in an adequate environment such as the processing unit 5 of the system 3 as shown in
Workflow aspects of a mechatronic object 2-i can run their own tasks and interact with workflow aspects of other mechatronic objects as well as with their technical environment. Mechatronic objects 2-i can be instantiated by the environment at any time. If they are not already instantiated during engineering by the engineering system the workflows can be instantiated and executed at runtime.
In a further possible variant, workflow aspects are not executed, but interpreted. In this implementation or embodiment, the workflow aspects of the mechatronic objects 2-i do not comprise code or definitions which can be executed directly. In this embodiment, the information of the workflow aspect is interpreted by a runtime system evaluating the mechatronic objects 2-i. The runtime system can comprise an algorithm how to evaluate the workflow aspects, when the workflow aspects store compatible information for the algorithm and the needed data. Workflow aspects can be integrated in the environment. Possible implementations of the workflow aspects can be described in a predetermined language to be interpretable. When the user creates or generates a workflow aspect for a mechatronic object 2-i, he either uses this predetermined language directly or a graphical user interface GUI can be provided which allows the user to design the workflow aspects by selecting and combining standard workflow elements including a workflow tool such as ARIS.
In an example embodiment, a defined workflow exists in the engineering system which is either a standard workflow or which is created for a specific engineering project within the engineering system. In an example embodiment workflow aspects of a mechatronic object 2-i can contain only configuration data for this workflow. The interpreter executes a workflow and looks up the configuration data from the respective mechatronic objects 2-i, i.e. the interpreter loads configuration data from the mechatronic objects 2-i. These configuration data can be defined unambiguously at least for this engineering system in order to be interpretable. It can also be that a graphical user interface, GUI, guides a user through the configuration possibilities for the currently processed mechatronic object 2-i. Thus, the engineering system can aggregate all configuration possibilities which can be set by a mechatronic object 2-i and can present a generated list to the user for parameterization. In a further possible implementation, each mechatronic object 2-i defines the necessary data which has to be created or generated in order to finish work on this mechatronic object 2-i during engineering. A standard workflow can collect this information and check a state of each mechatronic object 2-i in order to combine them to an overall state. Dependent on this overall state, the standard workflow can both generate a list of unfinished objects and trigger a user to finish them or it may acknowledge the completion of the engineering step and trigger the next workflow step. In addition to the described three possibilities, any combination thereof is possible.
In an example embodiment, passive workflow aspects can be used by active aspects which allows a lean creation of simple mechatronic objects 2-i. The passive workflow aspects of simple mechatronic objects 2-i can then be used by higher-level mechatronic objects with active workflow aspects. For example, a mechatronic object 2-i can define actions which have to be executed: a higher-level mechatronic object can execute these actions integrated with its own workflow aspects by interpreting the description of this passive workflow aspect.
In certain embodiments, the system may provide the advantage that the mechatronic data structure can be instantly considered in the workflow, thus making iterative work and changes easier and more reliable.
The need for a generation of the workflow may be eliminated, which may save time for filling the workflow system and updating it after changes have been performed.
Further, the possibility that workflow and the engineering get out of synchronization may be reduced or eliminated. The workflow can be provided directly by the mechatronic object 2-i which means less effort, less time and higher quality in case of reusable mechatronic objects.
A further possible advantage of certain embodiments is that the workflow information can be assigned to exactly that mechatronic object 2-i to which it belongs which makes it easier to comprehend and define a workflow in comparison to a monolithic workflow definition approach.
Finally, certain embodiments of the method and system may provide a high flexibility for the user. The integrated workflow aspects of the mechatronic objects 2-i may enforce a well-regulated working which is less error-prone and faster and may make it possible to employ a less experienced work force for engineering tasks.
In an example embodiment, the mechatronic objects 2-i have several workflow aspects which can be designed in a library and are used in a project during the engineering phase. When such a mechatronic object 2-i is instantiated, then the workflow aspects of this mechatronic object 2-i are activated and belong to the phase engineering, e.g. a workflow aspect may define and control the workflow for parameterizing the mechatronic object 2-i which requires input from different disciplines, for example, a workflow aspect assigned a task to a mechanical engineer, an electrical engineer or an automation engineer.
The workflow system in the engineering system according to certain embodiments can be set up before the project and on the one hand it can define the role of different users such as mechanical engineer, electrical engineer and automation engineer and, on the other hand, it can assign real persons to these defined roles. The workflow system can use this information to inform the appropriate users or engineers. The engineers are triggered either by the workflow system or engineering system or the respective workflow aspect itself. Then they can provide their input such as parameterization of the mechatronic objects 2-i. The engineers can acknowledge changes and confirm the completion of the assigned tasks. The mechatronic object 2-i can accept the changes and can acknowledge the fulfilment of a workflow aspect and may proceed further with the workflow.
If a project enters the next phase, for example the commissioning phase, then any workflow aspect of the interface, such as the commissioning phase, can be activated. For example, if a commission requires to fill in a test protocol for the correct functioning of the mechatronic object 2-i.
As long as a workflow aspect does not complete a mechatronic object, it is in a specific state, such as “in-work” relative to its project phase. The workflow system or engineering system can display a state and make sure that all mechatronic objects 2-i are still in this specific state to be recognizable by the relevant users. The system can always a current state of the project. Further, the states can be aggregated by the engineering system and processed for the user, e.g. project accomplished to 80%.
Either a mechatronic object 2-i or the workflow system or engineering system 3 can actively send messages to the roles which have a task assigned. The messages can then be forwarded to the assigned persons. A workflow aspect can relate to a whole mechatronic object 2-i or to a single facet of a mechatronic object 2-i, for example, a mechatronic object “pumping station” can contain a workflow description about general workflow information needed for integration regarding the pumping station, such as status information for superordinated workflows, e.g. “not available”, “erected”, “tested” and “available”.
The mechatronic objects 2-i may contain detailed workflow descriptions on a general level, but also on a facet level, e.g. the mechatronic object 2-i may describe in an activity or by defining split activities how to erect or to automate the pumping station, but it can also specify skills needed for the design, commission and for the maintenance or even scrapping of the mechatronic object 2-i or can give information about dependencies to other mechatronic objects.
The pumping station as a mechatronic entity ME may be engineered only when the technical constraints on the pumping station are fully known, provided by adjacent mechatronic objects. Further, this information can be fully provided by predefined mechatronic object types or the information can be supplemented or changed in instances by the user when utilizing or instantiating the mechatronic object types in a project.
| Number | Date | Country | Kind |
|---|---|---|---|
| 11153858 | Feb 2011 | EP | regional |
