Building and tracking of an automation engineering environment

BACKGROUND

Design of large systems such as, for example, a baggage han ^¬ dling system is a multi-disciplinary project. As an example, the baggage handling system combines automation information (e.g., within the automation discipline), mechanical infor ^¬ mation (e.g., within the mechanical discipline), and electri ^¬ cal information (e.g., within the electrical discipline).

Traditionally, engineers within each discipline work on de- signing the system separately, and the engineers transfer da ^¬ ta between the different disciplines manually. For example, engineers within the automation discipline transfer data to engineers within the electrical discipline via email or through complex synchronization between programs via script- ing or, for example, Microsoft Excel®.

The manual synchronization of the discipline specific data is very time consuming and error prone. As an example, when an automation engineer introduces a new programmable logic con- troller for automating the baggage handling system to a design or model (e.g., a project), this information is to be communicated to the electrical engineers, so the electrical engineers can include the necessary electrical components within the programmable logic controller and can plan wiring. If this information is not communicated between the automa ^¬ tion engineers and the electrical engineers or is distorted, the designs by the automation engineers and the electrical engineers, respectively, may be negatively impacted. The large system may be designed and modeled using, for exam ^¬ ple, Automation Designer from Siemens®. An Automation Designer project, for example, stores engineering objects that are organized in multiple hierarchies. Each of the stored engi- neering objects has multiple views (e.g., aspects) including, for example, a function aspect, a location aspect, a product aspect, and an automation aspect. Each of the stored engi ^¬ neering objects has one or more connections with other engi- neering objects within a discipline and/or across other dis ^¬ ciplines. For example, an engineering object within the auto ^¬ mation discipline has connections with other engineering ob ^¬ jects within the automation discipline, and has connections with engineering objects within the mechanical discipline and the electrical discipline, respectively.

Each engineering object has a set of engineering properties (e.g., object properties) that are available to other engi ^¬ neering objects for collaboration. An object property for a first engineering object (e.g., a source object) may be linked to an object property for a second engineering object (e.g., a target object). This process involves extracting the object property from the source object and linking the object property with the target object. An engineer designing the system manually selects individual properties from the source object and the target object for linking. This process is re ^¬ petitive, time consuming, and prone to error.

SUMMARY

In order to react to changes within a multi-disciplinary automation project, navigation schemes that automatically search for and connect to engineering objects based on prede ^¬ fined relations in multi-dimensional hierarchies are defined within an engineering object of the automation project. The engineering object also includes an intelligent extraction port that automatically extracts predefined property data from a source engineering object when the source engineering object is connected to the engineering object.

In a first aspect, a method for automatically updating a mul- ti-hierarchal representation of a system includes identify ^¬ ing, for a first component included within the multi- hierarchal representation of the system, by a processor, a connection between the first component and a hierarchical po ^¬ sition within the multi-hierarchal representation of the sys ^¬ tem. A memory in communication with the processor stores the defined connection between the first component and the hier ^¬ archical position within the multi-hierarchal representation of the system. The processor automatically connects the first component and a second component included within the multi- hierarchal representation of the system based on the stored connection between the first component and the hierarchical position within the multi-hierarchal representation of the system.

In a second aspect, a non-transitory computer-readable stor ^¬ age medium stores instructions executable by one or more pro ^¬ cessors to automatically update a multi-hierarchal represen ^¬ tation of an engineering system. The instructions include de ^¬ fining, for a first component included within the multi- hierarchal representation of the system, one or more properties to be extracted from a type of component when the type of component is connected to the first component. The in ^¬ structions also include storing, by a memory in communication with the processor, the one or more defined properties to be extracted, and automatically extracting the one or more prop ^¬ erties from a second component when the second component is connected to the first component. A type of the second compo ^¬ nent is the same as the type of component, for which the one or more properties are defined. In a third aspect, a system for automatically updating a mul ^¬ ti-hierarchal representation of an engineering system includes a memory configured to store the multi-hierarchal rep ^¬ resentation of the engineering system. The stored multi- hierarchal representation of the engineering system includes a representation of a first component and a representation of a second component. The system further includes a processor in communication with the memory. The processor is configured to define, for the first component, a connection between the first component and a hierarchical position within the multi- hierarchal representation of the engineering system, one or more properties to be extracted from a predetermined type of component when a component of the predetermined type is con- nected to the first component, or a combination thereof. The processor is also configured to automatically connect the first component and the second component within the multi- hierarchal representation of the engineering system after the representation of the second component is stored in the memory, based on the defined connection between the first component and the hierarchical position within the multi- hierarchal representation of the engineering system. The processor is configured to automatically extract, after the first component and the second component are connected, the one or more properties from the second component when the second component is a same type of component as the predeter ^¬ mined type of component.

The present invention is defined by the following claims, and nothing in this section should be taken as a limitation on those claims. Further aspects and advantages of the invention are discussed below in conjunction with the preferred embodi ^¬ ments and may be later claimed independently or in combina ^¬ tion.

BRIEF DESCRIPTION OF THE DRAWINGS

The components and the figures are not necessarily to scale, emphasis instead being placed upon illustrating the princi- pies of the invention. Moreover, in the figures, like reference numerals designate corresponding parts throughout the different views.

Figure 1 illustrates an example of a multidisciplinary engi- neering system; Figure 2 illustrates an embodiment of a multidisciplinary system implementing a multidisciplinary engineering environment ; Figure 3 illustrates another embodiment of a multidiscipli ^¬ nary system;

Figure 4 illustrates another embodiment of a multidiscipli ^¬ nary engineering system;

Figure 5 illustrates exemplary aspect organization within a multidisciplinary engineering system;

Figure 6 is a flow chart diagram of one embodiment of a

method for automatically updating a multi- hierarchal representation of a system;

Figure 7 illustrates an example of a parent navigation

scheme ;

Figure 8 illustrates an example of a children navigation

scheme ;

Figure 9 illustrates an example of a port extraction naviga- tion scheme;

Figure 10 illustrates an example of a connected engineering objects navigation scheme; Figure 11 illustrates an example of a property extraction

navigation scheme;

Figure 12 illustrates exemplary template creation and instan ^¬ tiation with navigation schemes;

Figure 13 illustrates exemplary template creation and instan ^¬ tiation with nested navigation schemes; Figure 14 illustrates a flow chart diagram of one embodiment of a method for automatically updating a multi- hierarchal representation of a system; Figure 15 illustrates an example of an intelligent extraction port ;

Figure 16 illustrates an example of an intelligent extraction port ;

Figure 17 illustrates an example of an intelligent extraction port ;

Figure 18 illustrates an example of an intelligent extraction port;

Figure 19 is one embodiment of a system for building and

tracking an automation engineering environment.

DETAILED DESCRIPTION

A project within an engineering design environment stores ob ^¬ jects (e.g., engineering objects) that are organized in mul ^¬ tiple hierarchies. Each of the engineering objects represents a device within the engineering design environment. Each of the engineering objects has multiple views (e.g., aspects of the engineering objects) . For example, the multiple aspects include a function aspects, a location aspect, a product as ^¬ pect, and an automation aspect. Each of the engineering ob- jects has connections with other engineering objects within a same discipline (e.g., the automation discipline) and across other disciplines (e.g., the mechanical discipline and the electrical discipline) . As an example, due to the complex nature of the engineering objects and corresponding multi-dimensional hierarchies in automation engineering, navigation schemes that may be applied to any automation project are provided. The navigation schemes are executed in real time and search/navigate engi ^¬ neering objects within the project based on relationships in the multi-dimensional hierarchies. The navigation schemes of the present embodiments span and traverse multi-dimensional hierarchies, including vertical and horizontal relationships within the multi-dimensional hi ^¬ erarchies. The navigation schemes automatically react and up ^¬ date based on changes within the project within the engineer- ing design environment. The navigation schemes dynamically connect engineering objects as the project is being built.

An intelligent extraction port is also provided on any target engineering object. The intelligent extraction port is used to extract the defined properties from any source object.

Once a target object is connected to a source object, the in ^¬ telligent extraction port automatically extracts defined property meta-data from the connected source engineering ob ^¬ ject and updates the target engineering object with corre- sponding values from the source engineering object.

The intelligent extraction port may define how to extract properties from a source engineering object that does not yet exist (e.g., an engineering object that may be introduced in- to the project at a future time) . The intelligent extraction port is thus defined in a context independent way, and the intelligent extraction port may thus be used with any project data. The intelligent extraction port extracts the properties from the source engineering object as soon as the connection is established between the source engineering object and the target engineering object in real time.

The intelligent extraction port provides that engineering properties defined at the intelligent extraction port are ex- tracted from the connected engineering object once available. This mechanism decouples the preparation for the usage of da ^¬ ta external to an engineering object and availability of the external data defined in another step. In many cases, the preparation for the usage of the external data and the exter ^¬ nal data being made available are completed in different en ^¬ gineering phases (e.g., at different times) by people in dif ^¬ ferent roles. The intelligent extraction port enhances the reusability of templates and reduces errors in data extrac ^¬ tion.

Figure 1 illustrates an example of a multidisciplinary engi ^¬ neering system 100. The multidisciplinary engineering system 100 is used by engineers, for example, who work in teams on multi-disciplinary projects. The multidisciplinary engineering system 100 represents, for example, Automation Designer from Siemens®, which is a central engineering application that focuses on reusability, rule-based engineering, cross- discipline collaboration, and data integration. The multidis ^¬ ciplinary engineering system 100 improves the consistency of such projects, reduces the time and cost invested in the pro ^¬ ject, and increases the productivity of the entire production engineering process.

Figure 2 illustrates an embodiment of a multidisciplinary system 200 implementing a multidisciplinary engineering environment. The multidisciplinary system 200 includes a server 201, a network 203 and workstations 205. Additional, differ- ent, or fewer components may be provided. For example, addi ^¬ tional or fewer workstations 205 are used. As another exam ^¬ ple, additional networks and/or servers are used. In yet an ^¬ other example, separate databases are managed and/or accessed by the server 201 and workstations 205. Server 201 is a serv- er computer platform having hardware such as one or more central processing units (CPU) , a system memory, a random access memory (RAM) and input/output (I/O) interface ( s ) . The server 201 is implemented on one or more server computers connected to network 203. Additional, different or fewer server compo- nents may be provided.

The workstations 205 are configured to execute at least one engineering application, such as engineering applications 305 discussed below. Alternatively, each workstation 205 may be configured to run all engineering applications, or configured to execute one engineering application per workstation 205. Additionally, the workstations 205 may be configured to exe- cute engineering applications stored on server 201. Each en ^¬ gineer, designer, technician, manager and other user is provided with login credentials, such as a username and pass ^¬ word, to access the engineering applications. Each user may access the engineering application and related information based on her role on the project, and access may be set ac ^¬ cording to permissions associated with each set of login cre ^¬ dentials .

Figure 3 illustrates another embodiment of a multidiscipli- nary engineering system 300. Engineered devices and other ob ^¬ jects such as, for example, a conveyor on a factory assembly line are represented in the multidisciplinary system 300. The multidisciplinary engineering system 300 includes a server in communication with workstations. The server and/or work- stations in the multidisciplinary engineering system 300 include engineering applications for various engineering disci ^¬ plines. The engineering applications are directed to, for ex ^¬ ample, layout design, electrical design, mechanical design, automation design, and business functions. The engineering applications correspond to engineering disciplines, such as factory design, electrical engineering, mechanical engineering, automation engineering, and project management. Each engineering application presents data differently, in a manner suited for the specific engineering discipline. Additional, different, or fewer engineering applications and engineering disciplines may be provided. Alternatively, at least one of the engineering applications is directed to two or more engi ^¬ neering disciplines within a single application. Various engineers, designers, technicians, managers and other users ac- cess the engineering applications to complete tasks on the project. For example, in the context of an automobile facto ^¬ ry, various engineers, designers and project managers plan a new production line for a car door assembly. Figure 3 shows an example. The new production line includes the conveyor. Each engineering application has its own role with respect to the conveyor, and will have a representation of data associated with the conveyor specific to the engineering applica- tion.

Factory designers utilize the layout design application, such as line designer application 301, to plan the layout of the new production line, including the conveyor. The line design- er application 301 displays information about which plan, line, zone, and station where the conveyor will be placed. Automation engineers utilize the automation designer application 303 to plan the conveyor automation. Automation designer application 303 displays the function and robot cell of the conveyor, and the components of the conveyor that will be au ^¬ tomated, including sensorl, sensor2 and motorl . Mechanical engineers utilize a mechanical design application, such as MCD 305, to plan the mechanical aspects of the conveyor. MCD 305 includes information about a three-dimensional (3D) model of the conveyor, including facel, face2, curvel and curve2.

Electrical engineers utilize the electrical designer applica ^¬ tion 307 to plan the electrical inputs and outputs for the conveyor. Electrical designer application 307 displays electrical information that will be provided to technicians in- stalling the conveyor. Electrical sheet 1 includes an AC pow ^¬ er output, Motorl input, Sensorl input and Sensorl output. Electrical sheet 2 includes a sensor2 input and sensor2 out ^¬ put. Additional and different roles and/or information may be provided .

Each of the engineering objects represented within the multi- disciplinary engineering system 100, 200, or 300, for example, has multiple views or aspects. The engineering objects have connections with other engineering objects within a same discipline and/or across other disciplines. Figure 4 illus ^¬ trates another example of a multidisciplinary engineering system 400. An engineering object 402 has, for example, a function aspect 404, a product aspect 406, and a location as- pect 408. The engineering object 402 may have more, fewer, and/or different aspects.

The function aspect 404 is used by the engineers working on the project, for example, to highlight the functional rela ^¬ tions among components of the engineering object 402. The product aspect 406 is used to highlight constructional rela ^¬ tions (e.g., an assembly) of the components of the engineer ^¬ ing object 402. The location aspect 408 is used to highlight the spatial relations among the components of the engineering object 402.

Figure 5 illustrates aspect organization within a multidisci- plinary engineering system (e.g., the multidisciplinary engi- neering systems 100, 200, 300, and 400) . The aspect organiza ^¬ tion provides hierarchies of engineering objects (e.g., engi ^¬ neering objects 402) according to, for example, IEC 81346. Other structuring principles may be used. As shown in Figure 5, some engineering objects 500 within the hierarchies only have a single aspect (e.g., a function aspect or a product aspect), while other engineering objects 502 within the hierarchies have multiple aspects (e.g., a function aspect and a product aspect) . Within a multidisciplinary engineering environment implemented by a multidisciplinary system, a property or engineering data (e.g., a rated power for a motor type) is to be extract ^¬ ed from a source engineering object for use by a target engi ^¬ neering object. In the prior art, however, an actual value for the property may only be extracted if the motor type

(e.g., the source engineering object), for example, exists within the multidisciplinary engineering environment and is connected to the target engineering object. The present em ^¬ bodiments provide navigation schemes and intelligent extrac- tion ports for connection to and proxy data, respectively, for engineering objects to be placed within the multidisci ^¬ plinary engineering environment in the future. Figure 6 is a flow chart diagram of one embodiment of a meth ^¬ od 600 for automatically updating a multi-hierarchal repre ^¬ sentation of a system. The system may be an engineering system such as, for example, a baggage handling system. Other engineering systems may be represented. The method 600 is performed in the order shown or other orders. Additional, different, or fewer acts may be provided. For example, the method may be performed without acts 606 and/or 608. In one embodiment the multi-hierarchal representation of the system includes at least a first representation of the system and a second representation of the system. For example, the first representation of the system is a representation within a first discipline and the second representation of the sys- tern is a representation within a second discipline. The first discipline is, for example, different than the second disci ^¬ pline. As an example, the first discipline is mechanical en ^¬ gineering, electrical engineering, or automation engineering, and the second discipline is mechanical engineering, electri- cal engineering, or automation engineering. The multi- hierarchal representation of the system may include more or fewer representations of the system. For example, the multi- hierarchal representation of the system may include a third representation of the system within a third discipline, and each of the first discipline, the second discipline, and the third discipline is a different discipline.

In act 602, a processor identifies or defines, for a first component included within the multi-hierarchal representation of the system, a connection between the first component and a hierarchical position within the multi-hierarchal representa ^¬ tion of the system. The first component is, for example, a first engineering object within the multi-hierarchal repre ^¬ sentation of the system. The processor defining the connec- tion between the first component and the hierarchical posi ^¬ tion may include, for example, receiving data related to the connection from a user of a multidisciplinary system or identifying the connection stored in a memory based on, for exam- pie, a type of the first component (e.g., representing a mo ^¬ tor, a sensor, etc.) . The processor may be a processor of a server, a workstation, another computing device, or may include a number of processor in communication via a network.

In one embodiment, the processor is a processor of a server. A user at a workstation in communication with the server defines the connection between the first component and the hi ^¬ erarchical position and transmits the defined connection to the server. In one embodiment, a memory in communication with the processor stores the defined connection between the first component and the hierarchical position within the multi- hierarchal representation of the system. The memory may be a memory of the server, another server, the workstation, anoth- er workstation, and/or another computing device. The processor of the server identifies the stored connection.

A representation of the first component includes a plurality of hierarchal views (e.g., aspects) . For example, the plural- ity of hierarchal views include a function view, a location view, a product view, and an automation view. In one embodiment, defining the connection between the first component and the hierarchical position within the multi-hierarchal repre ^¬ sentation of the system includes identifying, by the proces- sor, a hierarchal view of the plurality of hierarchal views.

Defining the connection between the first component and the hierarchical position within the multi-hierarchal representa ^¬ tion of the system also includes identifying, by the proces- sor, a number of levels to move up or down the identified hi ^¬ erarchal view from a first level within the identified hier ^¬ archal view to a second level within the identified hierar ^¬ chal view. The first level corresponds to a level of the first component.

In one embodiment, a navigation scheme identifying the number of levels to move within the identified hierarchal view is stored with the first component. The navigation scheme may be defined by a user at a workstation in communication with the server, or the navigation may be predefined within the first component (e.g., as part of a template for the first compo ^¬ nent) . The navigation scheme identifying the number of levels to move within the identified hierarchal view may be stored with the hierarchical view to be traversed at the first com ^¬ ponent, for example.

The navigation scheme identifying the number of levels to move within the identified hierarchal view may be, for exam ^¬ ple, a parent navigation scheme or a children navigation scheme .

As shown in Figure 7, the dotted line represents a parent navigation scheme. In the example shown in Figure 7, an auto ^¬ mation engineer, for example, has defined two navigation scheme objects to reach a parent that is two levels above a starting engineering object "E03" (e.g., the first compo ^¬ nent) . The navigation schemes are stored at the first compo- nent, for example, but results are returned based on the as ^¬ pect that is used for navigation. For example, if the func ^¬ tion aspect is used, then the parent navigation scheme de ^¬ scribed above returns "F01" (e.g., corresponding to the sec ^¬ ond level), starting from "FG01" (e.g., corresponding to en- gineering object "E03") ; if the location aspect is used, then "L01" is returned, starting from "LG01".

As shown in Figure 8, the dotted line represents a children navigation scheme. In the example shown in Figure 8, an auto- mation engineer, for example, has defined one navigation scheme object to reach the children that are one level below a starting engineering object "E02" (e.g., the first compo ^¬ nent) . The navigation schemes are stored at the first compo ^¬ nent, for example, but results are returned based on the as- pect that is used for navigation. For example, if the func ^¬ tion aspect is used, then the children navigation scheme described above returns "FG01" (e.g., corresponding to the sec ^¬ ond level) and "DF", starting from "FM01" (e.g., correspond- ing to engineering object "E03") ; if the location aspect is used, then "LG01" and "DL" are returned, starting from

"LM01" . In act 604, the processor identifies a component included within the multi-hierarchal representation of the system corresponding to the second level within the hierarchal view identified within act 602. As shown in Figure 9, the dotted lines represent two parent navigation schemes and one port extraction scheme, respectively. With reference to the func ^¬ tion aspect, the second level within the identified hierar ^¬ chal view is, for example, the parent that is two levels above the starting engineering object "E03" (e.g., "F01") . As shown in the example of Figure 9, the component corresponding to the second level within the hierarchal view identified within act 602, is at a same level as the parent returned, "F01". In one embodiment, the component identified in act 604 is the second component. In act 606, the processor identifies a port of the component identified in act 604. The identification of the port of the component identified in act 604 acts as a port extraction navigation scheme. In one embodiment, the first component is within the first representation of the system, and the second component, to which the first component is to be connected, is within the second representation of the system. The extracted port may be used to dynamically connect the first component (e.g., engineering object "E03") with the second component (e.g., another engineering object such as "E01") , which is within a different discipline than the first compo ^¬ nent. For example, the first component from a mechanical lay ^¬ out may be automatically connected with an engineering object from automation engineering. As shown in Figure 9, the port extraction navigation scheme extracts a port from the component identified in act 604, en ^¬ gineering object "E01". The port identified in act 606 is, for example, port "KK" . In act 608, the processor identifies another component within the multi-hierarchal representation of the system having the port identified in act 606. In one embodiment, the other com- ponent identified in act 608 is the second component.

Figure 10 illustrates a connected engineering objects naviga ^¬ tion scheme. This navigation scheme is used to extract the engineering objects that are connected to a given source en- gineering object (e.g., engineering object ^λ Έ01" having the port "KK") . As shown in the example of Figure 10, engineering objects "E04" and "E05" have ports "KK", respectively, and the processor, using the engineering objects navigation scheme, identifies the engineering objects "E04" and "E05" as having matching port "KK" with the port identified in act 606 for engineering object ^λ Έ01".

Other navigation schemes may be provided. For example, Figure 11 illustrates a property extraction navigation scheme. The property extraction navigation scheme is used to extract a single property from another engineering object (e.g., the second component) . The property linking and value flow hap ^¬ pens automatically upon connection. In one embodiment, a nesting navigation scheme is provided as a reusable solution within the multi-hierarchal representa ^¬ tion of the system. A template in a multi-disciplinary engineering system provides a scope for engineering data that may be prepared for reuse in a different engineering context (e.g., an engineering project for a baggage handling system) . The different engineering disciplines may contribute data with respect to corresponding domain needs.

Templates within a multi-disciplinary engineering system pro- vide that engineering objects may be grouped as a template in a discipline, and linked with corresponding data in other ap ^¬ plications and/or disciplines. A collection of engineering objects are thus identifiable across all of the disciplines within the multi-disciplinary engineering system.

Figure 12 illustrates exemplary template creation and instan- tiation with navigation schemes. In a standard workflow, an automation engineer creates, for example, a template for a conveyor with a motor, a drive, and sensors in a defined or ^¬ der. Templates may be created for other devices within the multi-disciplinary engineering system. When a template is in- stantiated within a discipline, all the corresponding linked library templates of the other disciplines, which are stored in the memory or another memory, for example, and corresponding stored navigation schemes are also instantiated. The pro ^¬ cessor automatically finds and evaluates the navigation schemes and updates values for the engineering objects within the multi-disciplinary engineering system as engineering objects are added.

Figure 13 illustrates how navigation schemes may be nested, and results from the navigation schemes may be used to create a next navigation scheme.

In act 610, the processor automatically connects the first component and the second component included within the multi- hierarchal representation of the system based on the defined connection between the first component and the hierarchical position within the multi-hierarchal representation of the system. In one embodiment, the second component is not yet included within the multi-hierarchal representation of the system when the connection between the first component and the hierarchal position within the multi-hierarchal represen ^¬ tation of the system is defined. In one embodiment, the first component and the second component are already connected, and in act 610, the first component and the second component au- tomatically communicate with each other using the navigation schemes described above. Due to the automatic connection of the first component and the second component in act 610, data may be shared between the first component and the second component. For example, a mechanical engineering works with the first component within a first application at a first workstation, and an electrical engineer works with the second component within a second ap ^¬ plication at a second workstation in communication with the first workstation via a server and a network. Due to the connection in act 610, data needed by the electrical engineer at the second workstation may be automatically transmitted from the first workstation and/or the processor of the server.

Other navigation schemes may be defined at the first compo ^¬ nent, for example. As an example, a property extraction navi- gation scheme may be defined at the first component. The property extraction navigation scheme is used to extract a single property from an engineering object. Property linking and value flow happens automatically upon connection. In one embodiment, the navigation schemes automatically gen ^¬ erate calling sequences of program blocks that are to be exe ^¬ cuted based on the automation engineering structure, for ex ^¬ ample. The navigation schemes automatically create, for exam ^¬ ple, PLC program blocks that may be exported and executed in a TIA portal. The navigation schemes adapt and change the PLC program and call the hierarchy automatically by reacting to changes in the engineering environment.

Many sensors and actuators are represented by tags (e.g., global variables) in PLC programs, and the sensors and actua ^¬ tors are to have unique names within the scope of the PLC. Many of the tags are parts of reusable solutions (e.g., tem ^¬ plates) that are instantiated a number of times. In one em ^¬ bodiment, to provide a unique name for tags, formulas that derive a unique name from an aspect structure, for example, may be used. Relative navigation is used to identify all an ^¬ cestors of a tag located somewhere within an aspect structure to derive a valid name. Program blocks are used in templates and represent a part of the PLC program. The program blocks are to be parameterized regarding individual and automation components (e.g., sensors and actuators) . Relations within the template may be set by absolute relations, but relations to external target engi ^¬ neering objects (e.g., the second component in a different discipline) are defined by using relative navigations. This provides that connections are created dynamically once the template is used, moved, or copied in a project context.

One or more of the present embodiments provide a set of navi ^¬ gation schemes used to traverse multi-hierarchy structure of an automation project. The navigation schemes may be applied in isolation or may be nested together such that the naviga ^¬ tion schemes are applied in a specific order.

Figure 14 is a flow chart diagram of one embodiment of a method 1400 for automatically updating a multi-hierarchal representation of a system. The system may be an engineering system such as, for example, a baggage handling system. Other engineering systems may be represented. The method 1400 is performed in the order shown or other orders. Additional, different, or fewer acts may be provided. The method 1400 may be performed in parallel with, in series with, or without the method 600.

In act 1402, a processor defines, for a first component in ^¬ cluded within the multi-hierarchal representation of the sys- tern, one or more properties to be extracted from a type of component when the type of component is connected to the first component. In other words, the processor generates an intelligent extraction port. As shown in Figure 15, the intelligent extraction port ex ^¬ tracts, for example, control voltage, power, and supplier in ^¬ formation from any connected motor. Different properties may be extracted, and/or different engineering objects types (e.g., component types) to be connected may be defined. In one embodiment, a memory in communication with the processor stores the one or more defined properties to be extracted. For example, the processor is a processor of a server, and the server stores the one or more defined properties to be extracted .

In act 1404, the processor automatically extracts the one or more properties from a second component when the second com- ponent is connected to the first component (e.g., with the method 600) . A type of the second component is the same as the type of component, for which the one or more properties are defined. The defined properties may only be extracted if the first component is connected to, for example, the defined type of component. For example, with reference to the example dis ^¬ cussed above, the processor only extracts the defined proper ^¬ ties when the first component is connected to a motor within the multi-hierarchal representation of the system.

Referring to Figures 15-18, as soon as the intelligent ex ^¬ traction port is connected to a motor instance (e.g., accord ^¬ ing to the method 600), the intelligent extraction port, via the processor, automatically extracts, for example, the prop ^¬ erty values for control voltage, power, and supplier from the source engineering object (e.g., the second component) and updates the linked property values of the target engineering object (e.g., the first component, representing a conveyor) in real time. The intelligent extraction port may extract in ^¬ formation (e.g., the property values) from engineering ob ^¬ jects of other engineering disciplines such as, for example, mechanical engineering, electrical engineering, automation engineering, and/or other engineering disciplines. The intel- ligent extraction port is generic in that the intelligent ex ^¬ traction port may be applied to engineering objects within the same and different engineering disciplines. In one embodiment, the multi-hierarchal representation of the system includes at least a first representation of the system and a second representation of the system. The first repre ^¬ sentation of the system is a representation within a first discipline, and the second representation of the system is a representation within a second discipline. The first disci ^¬ pline is different than the second discipline. The first dis ^¬ cipline is, for example, mechanical engineering, electrical engineering, or automation engineering, and the second disci- pline is, for example, mechanical engineering, electrical en ^¬ gineering, or automation engineering. More, fewer, and/or different representations within more, fewer, and/or differ ^¬ ent disciplines may be provided for the multi-hierarchal rep ^¬ resentation of the system.

In one embodiment, the second component is not yet included within the multi-hierarchal representation of the system when the one or more properties to be extracted are defined. In other words, the connection between the first component and the second component will happen in the future, and the in ^¬ telligent extraction port automatically extracts the defined property meta-data from the connected source engineering ob ^¬ ject and updates the target engineering object with the val ^¬ ues from the source engineering object when the source engi- neering object is placed and/or defined within the multi- hierarchal representation of the system.

One or more of the present embodiments provide an intelligent extraction port on a target engineering object to extract de- fined properties from any source engineering object within a multi-hierarchal representation of a system. The intelligent extraction port is stored with the target engineering object. Once a source engineering object of a particular type is con ^¬ nected to the target engineering object within the multi- hierarchal representation of the system, the intelligent ex ^¬ traction port automatically extracts the defined property me ^¬ ta-data from the connected source engineering object and up- dates the target engineering object with the values from the source engineering object.

The intelligent extraction port may define how to extract properties from a source engineering object that is not yet included within the multi-hierarchal representation of the system. As a result, a design engineer is able to prepare da ^¬ ta exchange in an engineering environment with nested objects without the need for specific engineering objects already be- ing included within the engineering environment. The intelli ^¬ gent extraction port provides that engineering properties de ^¬ fined at the intelligent extraction port will be extracted from the connected engineering object once the connected en ^¬ gineering object is available. This mechanism decouples the preparation for the usage of external data and availability of the external data defined in another step of the design process. This approach enhances the reusability of solutions (e.g., templates) and reduces errors. Figure 19 shows one embodiment of at least part of a system for building and tracking an automation engineering environment. The system is shown as a simplified block diagram of an example apparatus 1900. The system is a personal computer, laptop, tablet, workstation, mainframe, server, smart phone, or other computer device. The apparatus 1900 includes soft ^¬ ware and/or hardware to perform any one or more of the activ ^¬ ities or operations described herein.

The apparatus 1900 includes a processor 1902, a main memory 1904, secondary storage 1906, a wireless network interface

1908, a wired network interface 1910, a user interface 1912, and a removable media drive 1914 including a computer- readable medium 1916. A bus 1918, such as a system bus and a memory bus, may provide electronic communication between the processor 1902 and the other components, memory, drives, and interfaces of apparatus 1900. Additional, different, or fewer components may be provided. The components are intended for illustrative purposes and are not meant to imply architectural limitations of network de ^¬ vices. For example, the apparatus 1900 may include another processor and/or not include the secondary storage 1906 or removable media drive 1914. As another example, the apparatus 1900 connects with a camera, sensor, and/or microphone.

Instructions embodying the acts or functions described herein may be stored on one or more external computer-readable media 1916, in main memory 1904, in the secondary storage 1906, or in the cache memory of processor 1902 of the apparatus 1900. These memory elements of apparatus 1900 are non-transitory computer-readable media. The logic for implementing the pro- cesses, methods and/or techniques discussed herein are pro ^¬ vided on non-transitory computer-readable storage media or memories, such as a cache, buffer, RAM, removable media, hard drive or other computer readable storage media. Computer readable storage media include various types of volatile and nonvolatile storage media. Thus, 'computer-readable medium' is meant to include any non-transitory medium that is capable of storing instructions for execution by apparatus 1900 that cause the machine to perform any one or more of the activi ^¬ ties disclosed herein.

The instructions stored on the memory as logic may be execut ^¬ ed by the processor 1902. The functions, acts or tasks illus ^¬ trated in the figures or described herein are executed in re ^¬ sponse to one or more sets of instructions stored in or on computer readable storage media. The functions, acts or tasks are independent of the particular type of instructions set, storage media, processor or processing strategy and may be performed by software, hardware, integrated circuits, firm ^¬ ware, micro code and the like, operating alone or in combina- tion. Likewise, processing strategies may include multipro ^¬ cessing, multitasking, parallel processing and the like. The memory (e.g., external computer-readable media 1916, in main memory 1904, in the secondary storage 1906, or in the cache memory of processor 1902) also stores pre-calculated information, numerical models, matrices, and data calculated during processing.

The wireless and wired network interfaces 1908 and 1910 may be provided to enable electronic communication between the apparatus 1900 and other network devices via one or more net ^¬ works. In one example, the wireless network interface 1908 includes a wireless network interface controller (WNIC) with suitable transmitting and receiving components, such as transceivers, for wirelessly communicating within the net ^¬ work. In another example, the wireless network interface 1908 is a cellular communications interface. The wired network in ^¬ terface 1910 may enable the apparatus 1900 to physically con ^¬ nect to a network by a wire, such as an Ethernet cable. Both wireless and wired network interfaces 1908 and 1910 may be configured to facilitate communications using suitable commu ^¬ nication protocols, such as the Internet Protocol Suite

(TCP/IP) .

The processor 1902, which may also be a central processing unit (CPU) , is any general or special-purpose processor capa- ble of executing machine readable instructions and performing operations on data as instructed by the machine readable in ^¬ structions. The main memory 1904 or other memory may be accessible to processor 1902 for accessing machine instructions and may be in the form of random access memory (RAM) or any type of dynamic storage (e.g., dynamic random access memory (DRAM)) . The secondary storage 1906 may be any non-volatile memory, such as a hard disk, which is capable of storing electronic data including executable software files. Exter ^¬ nally stored electronic data may be provided to the apparatus 1900 through one or more removable media drives 1914, which may be configured to receive any type of external media, such as compact discs (CDs) , digital video discs (DVDs) , flash drives, external hard drives, or any other external media. The processor 1902 is configured by the instructions and/or hardware .

A user interface 1912 may be provided in none, some, or all devices to allow a user to interact with the apparatus 1900. The user interface 1912 includes a display device (e.g., plasma display panel (PDP) , a liquid crystal display (LCD) , or a cathode ray tube (CRT) ) . In addition, any appropriate input device may also be included, such as a keyboard, a touch screen, a mouse, a trackball, microphone (e.g., input for audio), camera, buttons, and/or touch pad. In other em ^¬ bodiments, only the display (e.g., touch screen) is provided. The display portion of the user interface receives images, graphics, text, quantities, or other information from the processor 1902 or memory.

Additional hardware may be coupled to the processor 1902 of the apparatus 1900. For example, memory management units (MMU) , additional symmetric multiprocessing (SMP) elements, physical memory, peripheral component interconnect (PCI) bus and corresponding bridges, or small computer system interface (SCSI) /integrated drive electronics (IDE) elements. The appa ^¬ ratus 1900 may include any additional suitable hardware, software, components, modules, interfaces, or objects that facilitate operation. This may be inclusive of appropriate algorithms and communication protocols that allow for the ef ^¬ fective protection and communication of data. Furthermore, any suitable operating system is configured in apparatus 1900 to appropriately manage the operation of the hardware compo- nents therein.

While the invention has been described above by reference to various embodiments, it should be understood that many chang ^¬ es and modifications can be made without departing from the scope of the invention. It is therefore intended that the foregoing detailed description be regarded as illustrative rather than limiting, and that it be understood that it is the following claims, including all equivalents, that are in ^¬ tended to define the spirit and scope of this invention.