Creating an advanced engineering framework based on engineering objects requires the following three tasks to be implemented:

The core components of VE-Suite require several changes to support these tasks. These needs will be met through the extension of the current VE-Open CORBA interface, implementation of an XML Schema and respective API, and extension of VE-Xplorer to support the display of engineering objects in a virtual world. Other changes will be made to VE-Conductor and VE-CE.

XML schemas provide the basic structure by which information can be transferred within the VE-Suite engineering framework. While the ontology provides the broad framework that computers use to classify information sources without human input, the schema provides the means by which the data can be packaged to hold the information provided by a particular source. For example, the ontology defines an object that can be a human or an information provider. These objects, when broken down into an XML document, would be composed of veDataValuePairs and other veXMLObjects, described below. An example of such a document will be illustrated below, but first the basic XML elements that compose the description of an object will be described.

The schema is composed of a few key XML element types. The first type is the veXMLObject element:

This element type is the basis for all other elements within the VE-Open schema, enabling any other element type within the schema to be embedded or referenced in a generalized manner. This enables abstraction, hierarchy, and modularity to be embedded in the schema and is the enabling factor for these qualities to be present in the objects that the XML schema describes. Although a formality, this element type enables the logic to be complete when embedding and referencing derived veXMLObjects in other element types. The functionality that veXMLObject enables will be illustrated below in veCommand. The veCommand is the element type that is passed in the Query functions described earlier.

The second element type is the veDataValuePair:

The veDataValuePair type holds a descriptive name about the data it contains as well as a veXMLObject or raw xs:anyType. This flexibility enables veDataValuePair to be a generic container element that holds any form of data being processed by a particular object. Note that a veDataValuePair is a complete extension of a veXMLObject. This extension permits a veDataValuePair to be embedded within another veDataValuePair.

The third element type is veCommand:

This element type contains a descriptive name for the command in addition to an xs:sequence of veDataValuePairs. The command is constructed to enable any object to request or send a series of veDataValuePairs with information about the potential application of the data contained within. Because a veDataValuePair can contain any veXMLObject that is derived for the VE-Open XML schema, a veCommand can be used as the overall container to transmit information about objects and the attributes used to describe them. This information is transferred in the Query methods and the SetNetwork functions.

The previous three elements described (i.e., veXMLObject, veDataValuePair, veCommand) are the core building blocks of the VE-Open XML schema. Each of the following elements described will use the key elements in the construction of the descriptors for an object. veParameterBlock is a general component that contains information about general information sources within VE-Suite:

An example of a parameter block would be a reference to a VTK dataset. The property element is configured to maintain a list of custom elements for describing a particular information source. This list of elements may also contain a list of hardware specifications for a sensor array or for a CFD solver configuration.

CADNode describes the geometrical representations that are stored for a particular object.

The CADNode contains two unique features. First, the CADNode does not maintain its own geometrical information, but references a file that contains this information. Second, the element can contain information about how to apply high-fidelity lighting capabilities. These are stored in the attribute element. This element contains a CADAttribute, which maintains a GLSL program embedded in the CADAttribute.

The following veXMLObjects will be described to provide context for the XSLT example that follows. These elements are used to construct the connectivity between virtual objects that are modeled in a system. The first element examined is a vePoint:

A vePoint is primarily used by the software within VE-Suite that renders graphical representations of the network schematic for the system under review. vePoint is composed of two unsigned integers representing the X and Y locations of the point. Data types for a point are unsigned integers so that graphical widgets libraries can easily render the point location. Graphical widgets libraries typically work in whole numbers rather than decimal values. The second element utilizes vePoint and is a veLink:

A veLink is composed of the necessary components to link one system component to another. The descriptors for the two modules that the link couples are fully described in addition to the necessary information to draw the link. This choice was made so that, upon obtaining the link, the software would not only be able to describe the information in the link, but would also be able to draw it.

The third element for a network description in VE-Suite is the veNetwork:

It should be noted that the veNetwork element is relatively simple, but builds on the previous two elements for full description. A series of links composes veNetwork and provides information about how the network should be rendered by VE-Suite’s rendering software. veNetwork is essentially a graph composed of edges (e.g., veLinks) and vertices (e.g., veModels). The representation of veNetwork follows closely on that defined by the DOT language utilized by GraphViz. While the DOT language is not utilized internally by VE-Suite, this task remains as future work to leverage the DOT language in addition to the use of the Boost Graph Language. These tools enable VE-Suite to use graph decomposition algorithms and detection algorithms to determine disconnected and feedback sections of graphs.

As noted previously, the veModel represents the nodes on the graph. The veModel builds on all of the previous elements and has the main responsibility for containing the inputs, outputs, CAD, and raw stream data for a particular model representation. The veModel is the data container for an object. In reference to the classification of objects, the veModel contains the raw data that would tell other objects about itself. In addition to containing the object’s raw representational data, the veModel can also contain a veSystem, which will be described later. The purpose of this embedded element is to provide the user with the ability to:

This capability provides one of the main components that enable the core VE-Suite software framework to support a broad range of problem domains.

The key components in the veModel element are the veParameterBlock, CADNode, vecommand, and veSystem elements. These elements provide the necessary information for each core software engine in VE-Suite to produce the proper representation for the object. For example:

The attribute element within the veModel contains the classification data for other objects to determine how to handle data from a particular object. Currently, the classification data is limited and further implementation is left for future research.

The veSystem element is the overall element that links the disparate veModel and veNetwork elements. It is also the main element that is saved when writing out a ves file (i.e., the DOMDocument storing all of the objects) from VE-Suite. In addition to establishing a relationship between veNetwork and veModel, it also enables systems to be embedded within models. This element provides the capability to construct complex engineering objects within VE-Suite.

The veSystem element also provides the foundation to link multiple third-party solvers together. For example, when integrating an Aspen Plus flowsheet with another solver, the Aspen Plus solver and the other solver each looks like a single system to the VE-CE. Within each of the systems may reside complex subsystems, which are handled by their respective solvers. Any subsystem corresponds to a single computational unit connected to the VE-CE, which does not mean that subsystems cannot be broken in terms of information transfer across subsystem boundaries.