Abstract:
A process converts stand-alone data sources to an open standard based architecture and integrates data throughout disparate departments and organizations. Once the data is in an open environment, it is made available in a collaborative environment via Web-based applications. The process does not require that the data come under the control of a central database, rather each data owner retains control. The invention allows users to maintain original processes for conducting their day-to-day activities. With minor modification to client applications, role-based interconnectivity of data can be established to allow data elements to be re-used by all downstream users without re-entering data, thereby improving product and process knowledge, preventing errors, handling data arbitration, improving data visibility and flexibility for decision makers, and saving resources thereby allowing collaborators to focus on core business competencies.

Description:
FIELD OF THE INVENTION  
       [0001]     The invention relates generally to collaborative systems engineering and operations support environments. More particularly, the invention relates to a collaborative environment that integrates disparate logistic and supply support tools to enable fusion of data across departments and organizations.  
       BACKGROUND OF THE INVENTION  
       [0002]     All companies must integrate new technologies with older processes and legacy tools to successfully evolve and compete in changing business environments. While implementing new processes, it is essential to continue to utilize existing and older systems to maintain asset visibility during the life of the product as well as to gather data to be used to compile historical information regarding the product with which to improve and update existing processes. Timely and accurate information with regard to the location, movement, status, and identity of assets and processes facilitates an organization&#39;s ability to act upon gathered data to improve overall business performance. Without an efficient manner of integrating data from older systems, extensive resources are required to gather, analyze, present, and implement historical and ongoing information. Human integration of this data is extremely difficult, burdensome, and prone to errors. When multiple systems are employed in multiple geographic locations, these problems quickly compound.  
         [0003]     Conventional collaborative multi-disciplinary environments are used in the design, development, production, and support of complex systems. A collaborative multi-disciplinary environment links information from various multi-disciplinary groups involved with different aspects of a complex system to form a common information model that represents the complex system. A collaborative multi-disciplinary environment provides discipline-specific views of an information model and integrates the discrete tools and processes with a managed repository of information representing the complex system.  
         [0004]     Conventional collaborative engineering and operations environments allow the allocation of tasks to those persons or organizations with the experience and resources to most efficiently perform those tasks. The best allocation of tasks results in the best application of resources. In a collaborative support environment, all data is available to all contributors in real time, and all contributors may observe the same data at any time. Constraints upon the data and upon the products are imposed automatically as contributors dictate changes. Modifications to the products and processes are tracked automatically and pass immediately into a digital electronic documentation history of the current product or process under scrutiny. This allows for proper tracking of design improvements, fault analysis, inventory management, and any process by which multiple contributors may make individual contributions with an eye toward the collective output.  
         [0005]     Information management technologies and design tool capabilities provide the opportunity to facilitate collaborative engineering processes. These collaborative systems include system engineering and design organizations, as well as customer and industry program management, procurement, manufacturing, maintenance, user training, and operations management. Immediate access to the latest product information, as well as access to all associated historic information, tools, models, and simulations, enables greater reach and more rapid turnaround of design alternatives as well as more efficient management of inventory and ongoing operational processes. At the same time, product design engineers can achieve a higher level of confidence in their chosen designs since they may now consider a greater scope of pertinent design parameters and factors. Cost considerations and integration planning of deliberate obsolescence, inventory management, other manufacturing resource planning functions is available early and throughout the system life cycle and are more easily managed and complete in scope, enabling not only cost competitive system development, but optimized support of the released system.  
         [0006]     A collaborative engineering and operations environment provides an inter-enterprise mechanism for design engineers, systems integrators, contractors, suppliers, partners, users, and customers to communicate. The environment provides an architecture linking multiple systems and applications to enable collaboration to conceive, develop, produce, sustain, improve, and ultimately retire complex system products. Critical information is made readily available to every member of the extended enterprise. In this fashion, collaborative multi-disciplinary environments may be implemented to manage and leverage various activities among the disciplines involved. Using a collaborative multi-disciplinary environment, the various disciplines contributing to decisions associated with the complex system can exploit synergies that result from the timely and reliable exchange of information.  
         [0007]     However, current collaborative engineering and operations environments are deficient and require additional management to foster the necessary collaboration, as well as additional time and labor to coordinate and exchange information.  
         [0008]     The lack of true interconnectivity between departments and organizations that utilize diverse computer systems is a basic barrier to collaborative engineering environments and the true ability to accurately and reliably exchange data. While standards currently exist to support the sharing of design information across different operating systems and network protocols, conversion of the data to a common format and digital representation often serves to bottleneck the collaboration. Known systems and methodologies in the area of collaboration engineering and operations support environments all fall short.  
         [0009]     One of these deficient systems used to enable interaction in enterprise site planning is set forth in U.S. Pat. No. 5,931,900 (the &#39;900 patent) issued to Notani et al. This system enables interaction between different domains by employing an inter-domain connectivity plane with a first domain engine associated with the first domain and a second domain engine associated with the second domain engine. The first and second domain engines perform domain analysis functions. Additionally, the system employs adapters associated with the first and second native sources. The adapters abstract data and information from the first and second native sources onto the inter-domain connectivity plane. However, the system in the &#39;900 patent requires that the adapters be loaded to interface to particular sources of information. While the adapters may be stored and re-used, they must be accessed and run each time the particular source of information is accessed.  
         [0010]     Another system providing access to documents of different formats is set forth in U.S. Pat. No. 6,064,977 (the &#39;977 patent) and U.S. Pat. No. 6,301,621 (the &#39;621 patent) both issued to Haverstock et al. These systems employ a web server, a Hyper Text Markup Language (HTML) translator, and databases in which a variety of objects of different types are stored. The HTML translator converts non-HTML objects to HTML format and sends the HTML downloaded object to a client side browser for display. However, the systems fail to integrate applications but rather retrieve non-HTML objects using a non-HTML server and translate the objects each time they are requested. This is repetitive and an inefficient use of computing resources.  
         [0011]     Another deficient method and apparatus for collaboratively managing supply chains is set forth in U.S. Pat. No. 6,157,915 (the &#39;915 patent) issued to Bhaskaran et al. This apparatus appears to permit collaboration through domain task-specific active documents. However, this apparatus does not provide a manner in which data is compiled automatically and feedback is provided to appropriate users based upon operations management metrics, failure analyses, or other business processes.  
         [0012]     As is readily apparent to those of skill in the art, the above and other existing known systems and methodologies fail to provide a truly collaborative engineering and operations environment. None of these previous “collaborative” systems adequately addresses a logistic support system from product design to disposal. No system employs open architecture modules to follow the product from design concept to system requirements to manufacturing, to the supply chain, to obsolescence and disposal while providing real-time and continuous feedback regarding the performance of the individual outputs and the collective process.  
         [0013]     There is, therefore, a need for a new type of collaborative operations system and method that allows shared data to remain in its native format without conversion to provide engineers and others access to current data in a format that is readily accessible by their individual systems, thereby providing the ability to share data efficiently and effectively.  
       SUMMARY OF THE INVENTION  
       [0014]     The present invention relates to a collaborative engineering and operations support system, and in particular to a collaborative system with open architecture modules that seamlessly integrate design, engineering, manufacturing, production, supply chain, training, and documentation module data into a coherent usable tool. The process enables data fusion across departments and organizations that are geographically separate by using an effective, lost cost integration method.  
         [0015]     The method of the present invention allows users to maintain original processes for conducting their day to day activities, while at the same time preventing errors, handling data arbitration, and improving data visibility for decision makers. The method of the present invention does not require the user to add new software, re-train, or learn new processes.  
         [0016]     The present invention manages information assets by integrating data throughout disparate departments and organizations. By including different departments and organizations under the collaborative environment umbrella, product and process knowledge is shared regardless of its native format. This permits the enterprise to respond quickly and agilely to challenges as they occur. Data is automatically culled from documents used in operations and enterprise management, and the pertinent data is automatically provided to users as it becomes available. Responsiveness to both internal and external customers is greatly facilitated by permitting interactive access to product information assets for all members of the enterprise. The collective enterprise has potential access to the latest information including design updates, development timelines, product specifications, product modeling and simulation, trade study, inventory management, enterprise resource planning, and other engineering tools. This mechanism for information exchange between disparate locations and tool sets provides a tighter design mechanism and improved enterprise management of the product throughout its life cycle.  
         [0017]     Additionally, information assets such as designs, documentation, testing information, product history, and accumulated knowledge developed and utilized during the product life cycle may be re-used to facilitate consistency between products as well as to refine processes and assess metrics. The critical resources of the organization may then be leveraged throughout the enterprise as the disparate subject experts propagate their expertise throughout the enterprise. The challenges presented by rapidly evolving technologies, cost pressures, and short product delivery cycles may be met by extending the capabilities of single users throughout the enterprise. As tools, processes, knowledge, experience, and requirements change, the collaborative system of the present invention provides the ability to flexibly meet these requirements while conforming to core business rules. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0018]     The above-mentioned and other features and benefits of this invention and the manner of attaining them will become more apparent, and the invention itself will be better understood by reference to the following description of embodiments of the invention taken in conjunction with the accompanying FIGURES where:  
         [0019]      FIG. 1  is an illustration of a collaborative systems engineering and advanced logistics support environment in accordance with one embodiment of the invention.  
         [0020]      FIGS. 2A and 2B  are flow diagrams illustrating basic operations of the invention.  
         [0021]      FIG. 3  is a graphical representation of elements composing an asset life cycle as used in the present invention.  
         [0022]      FIG. 3A  is an illustration of modules composing the system of the present invention.  
         [0023]      FIGS. 4A and 4B  are flow diagrams illustrating methods of operation of the present invention. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0024]     The invention is described in detail with particular reference to certain preferred embodiments, but within the spirit and scope of the invention, it is not limited to such embodiments. It will be apparent to those of skill in the art that various features, variations, and modifications can be included or excluded, within the limits defined by the claims and the requirements of a particular use.  
         [0025]     The present invention is directed to a system and method for collaborative systems engineering and logistics support. The system and method permit accurate tracking of assets from design to disposal and provide relevant data regarding the asset to users throughout the asset life cycle. The present invention is implemented by the use of an application program on computers at stations where individual contributors perform their various work tasks and where others performing roles within the asset life cycle have occasion to view pertinent documents and data regarding the asset.  
         [0026]     Previous systems for collaborative systems engineering dictated asset tracking based upon that singular global system. With the present invention, stand alone applications programs may be replaced or upgraded without affecting the collaborative environment. The present invention enables the various individual contributors in the collaborative environment to utilize their personal applications while the systems engineering and advanced logistics system extracts data from the back end of the system. This enables future users, who may not use the same application program, to have access to legacy data objects. The data objects persist even if the application program with which they were created becomes outdated, or is replaced, or otherwise is no longer used in the collaborative environment.  
         [0027]     A key advantage to the system of the present invention is that the user is not beholden to one program or one system or one manufacturer. The collaborative user is able to pick and choose programs based upon their features and advantages. True interoperability and connectivity is delivered by the system of the present invention. The method of the present invention allows a seamless connection of all the disparate applications used within a collaborative environment.  
         [0028]      FIG. 1  illustrates a collaborative systems engineering environment  100  where individual contributors  105   a ,  105   b ,  105   c ,  105   d  may be located in different departments of a company, in different companies, in different cities, or in different countries throughout the world. For convenience and brevity, in  FIG. 1  four individual contributors are shown, but an unlimited number of individual contributors may use the collaborative systems engineering environment depicted in  FIG. 1 . Each individual contributor  105  is responsible for an element of a final work product, and the ability of multiple contributors to work simultaneously on separate aspects of the final work product allows for a synergy of efforts resulting in a quicker completion of a better work product, with work assigned to individuals based upon their unique skill set. The individual contributors exchange relevant information and tools and collaborate through a communications network  120  that links these individual contributors together so that each individual contributor has access to the in-progress work product of the others through communication devices  130   a ,  130   b ,  130   c ,  130   d  such as computer systems, telephones, and other communication devices. The communication network  120  transforms the separate and disparate individual contributors into an integrated virtual office environment  150  in which each contributor has ready access to the other individual contributors and the work in progress. This integrated virtual office environment  150  permits completion of projects and output of a high quality final work product in an extremely efficient manner.  
         [0029]     Overview  
         [0030]     While software modules are described, it is to be understood that all or a portion of the exemplary embodiments can also be conveniently implemented by the preparation of application-specific integrated circuits or by interconnecting an appropriate network of component circuits. For simplicity and brevity, an exemplary embodiment utilizing software modules is shown in  FIG. 2 .  
         [0031]     As illustrated in  FIG. 2 , the collaboration begins at step  210  when a problem or need is recognized. The problem may be recognized by any number of individuals, groups, or other institutional actors. Often a problem or need is recognized by a company&#39;s marketing department conducting market research or by a customer or potential customer that may desire a particular product with specific features or a general product to achieve a particular goal.  
         [0032]     Once the problem or need is recognized, the collaborative systems engineering process continues at step  215  as the actors clarify the problem and articulate a requirements object. The requirements object is the result of translating the need or the answer to the recognized problem into a top-level solution. The top-level solution may include general functionality of a product, price targets, sales projections, required resources, and a life cycle schedule.  
         [0033]     Once this requirements object is determined, it may be analyzed at step  220  and at step  225  pared down into various functional, system, and product requirements that serve to further define and constrain the design of the product. The group of collaborators determine a number of product design alternatives based upon the top-level solution and then evaluate the various design alternatives with regard to cost, quality, ease of manufacture, length of lead times, legal constraints, and any number of other design and manufacture specifications and process plans to arrive at the best design alternative at step  230 . The users call upon their individual skill sets to reach a consensus and choose the best design alternatives within the parameters established by the various business rules of the company.  
         [0034]     Once the best design alternative is chosen at step  240 , engineers design the selected product at  245  by utilizing schematic and block diagrams, initial bills-of-materials, pre-prototype simulations, mechanical and computer modeling, and engineering and specialty design reviews. At  247 , the engineers test and analyze the completed designs to ensure proper performance and verification in accordance with various business rules as well as to ensure that the finished product meets the requirements object initially set forth. Further, at step  248  the engineers prepare technical documentation including installation and field test manuals, calibration manuals, technical manuals, and user manuals to ensure the delivered product operates properly and within the parameters established by the requirements object and that the finished product may be properly serviced. Once the finished design has been properly tested and documented, production of the finished product occurs at  250 . Production scheduling, management of supplier networks, output requirements, packaging and storage, and equipment and facilities must all be managed properly under the production umbrella. The finished goods are then delivered to the customer at  255  to complete the sale and distribution. Once the finished goods are in the customers&#39; hands, the product must be installed and supported at  260 , and warranty costs, service costs, performance data of the finished goods, and customer satisfaction must be monitored. As the product matures, on-going service may be required, and design refinements or upgrades are inevitable over the product life cycle as the product is continually evaluated during its useful life and the need for improvements and updates is realized. Once the product has reached the end of its useful life at  270 , it must be disposed, and several options such as trading the product in, re-selling the product, recycling the materials, and scrapping the product are evaluated by the customer and by the organization to determine how each of the alternatives best fits within the business rules of the organization.  
         [0035]     In  FIG. 3 , a graphical representation of pieces that compose the asset life cycle is shown. Business rules established by the organization exert pressure upon each of the component pieces throughout the life cycle of the asset. Each of the stages of the asset life cycle must conform to established business rules to ensure that the product will be viable for the organization.  
         [0036]     At each point in the asset life cycle, a variety of users provide input to the processes involved. Each of the users may create documents or other data that is utilized to perform their specific work function and to add value to that piece of the asset life cycle. The information conveyed by these documents and data may later be used to make decisions that affect the asset further along its life cycle. The present invention provides a system and method with which the data utilized and the discrete work products generated by the individual contributors may be distributed and shared among the collective group performing work associated with the asset life cycle. The documents and work products contain underlying data characterizing the asset as it matures through its life cycle. Each user receives specific information regarding the asset that is pertinent to their own decision support processes to enable efficient and compatible assessments during the asset life cycle and to optimize future decisions regarding the asset.  
         [0037]     Documents and data utilized by the present invention are accessed by a communications network such as an intranet or the Internet to afford all users simultaneous access to the system and to the data. Similarly, proprietary networks, databases, and servers may also be used as the distributed computer system as long as all users may access the system to collaboratively manage and track the asset.  
         [0038]     Example of Operation  
         [0039]     To best understand the present invention, it is useful to track an asset through its life cycle and to examine the documents and data that touch or concern the particular asset and to then see how this data is shared throughout the enterprise by use of the system and method of the present invention.  
         [0040]     In tracking an asset through the system, at each step documents and data are created and examined. The structure of the collaborative system of the present invention provides software modules that perform the data creation, routing, analysis, storage, and other functions that form the backbone of the engineering and advanced logistics support activities. These modules are shown in  FIG. 3A , and portions of each of the modules may be used in all of the steps of performing the method of the present invention. The modules include an open architecture module  340  that provides data in its native format, an autonomous agent module  350  that sets and responds to trigger criteria and independently gathers data provided by the open architecture module  340  and processes tasks in the background, a workflow manager module  360  that polices and enforces business rules in data routing so that individual departments, organizations, and individuals are notified that the data was provided by the open architecture module  340  and performs specific tasks in an order in accordance with the business rules established by the autonomous agent module  350 , an infrastructure connectivity module  370  that provides a notification pathway for the workflow manager module  360  to route data by establishing and maintaining communication links between the individuals, departments, and organizations to allow collaboration, a report engine module  372  for extracting, formatting, and delivering data routed by the workflow manager module  360 , a root cause analyzer module  374  that analyzes data routed by the workflow manager module  360 , sets an alarm level to detect unwanted occurrences in the data, sets exclusions for the detection of unwanted data, determines the cause of the unwanted occurrence, and removes the cause of the unwanted occurrence, a data mining module  376  that analyzes data routed by the workflow manager module  360  to databases using tools and applications that look for trends and anomalies in the data, and a user interface  320  to access the open architecture module  340 , the autonomous agent module  350 , the workflow manager module  360 , the infrastructure connectivity module  370 , the report engine module  372 , the root cause analyzer module  374 , and the data mining module  376 .  
         [0041]     Define a Need  410   
         [0042]     Referring to  FIG. 4A , the asset life cycle begins when a problem or need is recognized  410 . The problem or need may be recognized as the result of a market survey  401  or a customer communication  404  or request or simply as the result of a memorandum  402  from one employee to another. Whatever the input that serves to identify the problem or need, the input can be stored as a document or converted to a document if the communication was by some other means  403 . The user, such as a marketing employee or other individual contributor, names and stores the document in its native format in a requirements database  4444  where it may be accessed by other users in the enterprise through the distributed computing environment.  
         [0043]     By using the open architecture module  340  previously described with regard to  FIG. 3A , the present invention presents users with documents in their native format, or if the native format of the document may not be utilized by the particular collaborative team member, the document or data object is presented in a standardized format according to the applications employed by the user. With the native format, or the standardized format, the users may locate and utilize pertinent data objects without searching through the organization. The present invention employs business rules described and warehoused in the autonomous agent module  350  of the organization to determine how the workflow manager module  360  delivers data objects and to whom the data objects are to be delivered.  
         [0044]     Returning to  FIG. 4A , as the market research report  401  document or customer communication  404  is stored in the requirements database  4444 , the document is assigned a file number. The present invention strips down and parses the data elements in the document into discrete data objects. The documents are parsed using both lexical analysis and semantic parsing. Lexical analysis focuses upon dividing the relevant document strings into generic tokens based on punctuation and other keys factors. These are the data objects. The document strings are then analyzed semantically to determine the meaning of the string and what the data elements represent. The invention then tags the data objects for reference, and assigns an owner, normally the creator of the document, to each discrete data object. The invention then inserts the data objects into database structures in the requirements database  4444 .  
         [0045]     For example, a customer communication is sent to the marketing group expressing a need for the world&#39;s fastest submarine. The marketing manager stores the customer communication document in the requirements database  4444 , and it is given a unique file name or other identification number that is used throughout the entire asset life cycle. Further, the date, time in hours, minutes, and seconds, is noted to ensure that collaborative documents are updated appropriately and that a collaborating user always is cognizant of the version with which they are working. As the document is stored, the data is stripped from the document and parsed into discrete data objects, one of which is the speed requirement. A one-to-many mapping is created. The marketing manager is assigned as owner of this data object.  
         [0046]     In this fashion, data objects of relevance to particular users or groups of users may be distributed based upon an owner or a user establishing a trigger criteria. Data trends may also be analyzed and users alerted to trends as they become evident.  
         [0047]     Translate Need into Requirements Object  415   
         [0048]     Continuing in  FIG. 4A , upon completion of this definition of a need, the need is translated into a requirements object, which is a high-level solution to the identified problem or need. The requirements object may be a concept of a solution, for example. In this instance, the present invention takes the speed requirement data object and automatically sends the document and the data object to the marketing group, the future projects group, the engineering management group, and others who possess unique skills necessary to formulate a conceptual solution to the customer&#39;s need and the requirements object. The present invention employs the workflow management module and the infrastructure connectivity module to deliver the data objects to the disparate groups and users over the distributed computer network in a format that is usable by the recipient. These disparate groups may then collaborate with each other over the distributed computing environment and come to a consensus with regard to a final requirements object. The communications between the collaborative group, such as emails, memos, sketches, FIGURES, and other communiqués, and the documents created and accessed during the consensus-building are also stored in the requirements database  4444 . These may include various proposals attempting to identify a requirements object and will ultimately include the consensus solution. Discrete data objects are also culled from these communiqués and delivered to appropriate team members in the collaborative environment by the present invention. In the example of a submarine that must be the world&#39;s fastest, the requirements object may be a submarine that travels in excess of 50 knots, that has a range of 10,000 kilometers, is manned by a crew of less than 100 seamen, and costs less than $10 million to produce. These discrete data objects are parsed from the documents outlining the requirements object and distributed throughout the collaborative environment in a useable format and stored in the requirements database.  
         [0049]     Analyze Requirements Object and Define Functional Requirements  420   
         [0050]     Once the requirements object is determined, it is analyzed and broken down into more modular functional requirements. The functional requirements describe systems and subsystems that in total satisfy the requirements object. Functional requirements may be described in flow string diagrams or other documents and data objects that are then parsed and stored in the requirements database  4444 .  
         [0051]     Define and Develop System Requirements  425   
         [0052]     The functional requirements are then translated into product and system requirements by defining the functions that the system and subsystems must perform to achieve the desired outputs, by defining interfaces between the functions, and by defining the requirements associated with each of the functions. In the submarine example, product requirements may include a steel hull that is less than 100 meters long and more than 20 meters wide, a propeller screw that is less than 5 meters in diameter, and a nuclear reactor capable of providing 200 MW of power to drive the submarine. Each of the product requirements documents is stored in the requirements database  4444  and parsed to pull discrete data objects from the document as a whole. These data objects may include information relating to the propulsion system, the defense system, the navigation system, and other key system subcomponents that may be logically separated from one another to provide discipline-specific bounds within which the different collaborating team members may operate. The documents are stored in the requirements database  4444 , and the invention delivers the data objects to appropriate users collaborating on the project. As the collaboration progresses, each user may add data objects or create new documents with additional information and additional data objects. For example, in addition to the requirement that the propeller screw be less than 5 meters in diameter, an engineering team collaborating on the project may also dictate the size, shape, and weight of the propeller screw, and employ the system of the present invention to link these additional product requirements as data objects to a variety of the functional objects describing the systems. These new data objects are then stored in the requirements database  4444  and distributed to appropriate users.  
         [0053]     Identify &amp; Evaluate Design Alternatives  430   
         [0054]     Once the functional and system requirements are defined, the collaborative team performs studies and analyses to refine and optimize performance requirements for each of the subsystems. The team defines evaluation criteria, describes the approaches to the studies, performs the evaluations, documents the results of the evaluations, and then selects the preferred system design according to their findings. At each point in the evaluation process, mechanical drawings, modeling procedures, historical data, test procedures, test results, and analyses documents may be used to substantiate the integrity of the evaluations as well as the integrity of the ultimate selection of the chosen design. These documents comprise data objects that relate to each of the examined criteria as well as to the observed results. With the propeller example, each propeller design is given a unique tracking number and stored in the drawings database  4445  and parts database  4446 . Additionally, the documents associated with the evaluation, as well as data objects relating to the propeller design, such as diameter, pitch, cupping, rake, and other objects are all stored in the same drawings database  4445  and parts database  4446  and are linked to the unique tracking number assigned to the particular propeller design. Each of the data objects corresponding to analyzed design variables are parsed and stored in the parts database  4446  and similarly linked to the appropriate evaluation document. Similarly, other propeller designs considered would also be given a unique tracking number, and the documents and data objects corresponding to those designs are likewise stored in the drawings database  4445  and parts database  4446  and linked with their unique tracking numbers.  
         [0055]     Select Preferred Design  440   
         [0056]     The team of collaborators determine a number of product design alternatives and evaluate the various design alternatives with regard to cost, quality, ease of manufacture, length of lead times, legal constraints, and any number of other design, manufacturing, and production variables to arrive at the best design alternative. The users call upon their individual skill sets to collaborate and to reach a consensus and choose the best design alternative within the parameters established by the various business rules of the company and implemented by the underlying autonomous agent module. The consensus decision is memorialized in any number of documents that are stored in the requirements database  4444  and the drawings database  4445 , with the data objects parsed and stored accordingly.  
         [0057]     Design Product  445   
         [0058]     Once the best conceptual design alternative is chosen, engineers design the selected product and parts of the product by utilizing Computer Assisted Design (CAD) systems to draw and build schematic and block diagrams, initial bills-of-materials, pre-prototype simulations, mechanical and computer models, and engineering and specialty design review documents. The engineers test and analyze the completed designs to ensure proper performance and verification in accordance with the various business rules as well as to ensure that the finished product meets the requirements object initially set forth. Data objects from the product design may be compared to those stored in the requirements database  4444  to ensure compliance. If the collaborative team approves the prototype design drawing, the elements comprising the parts drawings are assigned part numbers and stored in the parts database  4446  as data objects. Likewise, the composite drawings are also stored in the drawings database  4445  and linked to the data objects that comprise the drawings. These CAD drawings are then used to compile a functional bill of materials to which the propeller may be manufactured. If necessary, CAD drawings may be used to produce tooling drawings to be used in conjunction with a Computer Assisted Manufacturing (CAM) system to fabricate the parts.  
         [0059]     Test &amp; Analyze Completed Design  447   
         [0060]     Once the design is complete, the finished product is tested to ensure it meets performance, interoperability, reliability, packaging, and cost requirements. Members of the collaborative team analyze performance test criteria and resulting test data and then evaluate the results. Interoperability must be evaluated to ensure the finished product will properly function with existing components. The propeller screw must properly fit on the drive shaft. Tolerances must coincide and function properly. Reliability checks and redundancy evaluations are performed to ensure the product lasts for its designed lifecycle. Packaging tests may be necessary to ensure the finished product is within size and weight requirements and can withstand potentially hazardous shipping or delivery conditions to arrive in pristine condition for installation. Shipping containers for the propellers must be fabricated and tested for fit and durability. Cost considerations are factored in throughout the testing and analysis process to ensure that the finished product is delivered within budgetary constraints.  
         [0061]     Data objects associated with these test plans and the test results are extracted by the invention and stored in the parts database  4446  and the drawings database  4445 . Similarly, data objects related to ancillary items such as shipping containers are also tagged and extracted. Within this environment, the organization is able to eliminate potential problems years down the road when an older propeller might be produced and no one in the organization knows who made the shipping crate or how large it had to be. This type of institutional knowledge is preserved by storing the data objects related to the various products and parts. Similarly, the data objects are also linked to the requirements database  4444  for active comparisons to initially established requirements objects and performance constraints. Data objects of particular relevance are again extracted and sent to the concerned collaborators for further review and implementation as the process iterates.  
         [0062]     Prepare Technical Documentation  448   
         [0063]     The collaborating team prepares technical documentation including installation and field test manuals, calibration manuals, technical manuals, and user manuals to ensure the manufactured product operates properly and within the parameters established by the requirements object and that the finished product may be properly serviced. The technical documentation is then stored in the Interactive Electronic Technical Manual (IETM) database  4447 . The IETM is stored on a computer server, a CD-ROM, an HTML page, or on other means by which it may be accessed to provide user interactivity. The IETM database  4447  is linked to the parts database  4446  and the drawings database  44445  and provides hyperlinks to technical documents, parts lists, and drawings via the relational characteristics of the databases. The neural intelligence of expert systems is embodied in the IETM as it provides interactive assistance in installation and troubleshooting while eliminating paper copies of technical manuals. The IETM also ensures version control of referenced FIGURES, tables, drawings, procedures and other trouble-shooting instructions as the documents are stamped and coded with accurate version data objects.  
         [0064]     The IETM enables the user to hyperlink directly to a referenced item and access drawings, parts lists, bills of materials, technical notices, and other documents related to a particular part or subsystem. Additionally, in trouble-shooting sections of the electronic manuals, the user can highlight the current problem, and the IETM will then provide step-by-step instructions aimed at resolving the issue. The IETM does this by specifying sequential trouble-shooting tests and the possible results of the test and then branching the user to the next step of the logical troubleshooting process based upon the reported results. By providing this functionality, the IETM enables a user to access collaborative resources of the engineering and systems teams in the most relevant manner directed to the issue at hand. Additionally, failure data culled from performance of the installation checks and troubleshooting process may be used by the IETM expert system to provide additional assistance to future users. Likewise, data objects related to installation, calibration, and troubleshooting can provide insight as to the manufacturability of the individual products and subsystems as the individual items are related to cost data.  
         [0065]     Produce and Manufacture Product  450   
         [0066]     Once the finished design has been properly tested and documented, production of the finished product occurs. The final design and technical documents are formalized and are used in conjunction with a CAM system to fabricate the necessary parts that make up the product system, subsystem, or part. Production documents include orders of raw materials, bills of lading, invoices for raw materials, producer and supplier communications, production schedules, production outputs, production testing documents, equipment and facilities schedules, quality assurance tests and results, employee schedules, and other documents necessary to track and turn raw materials into the finished product. The required resources that are inputs to the collaboration comprise a vast trail of documents characterizing the production process and forming a store of institutional knowledge and experience related to the product or subsystem.  
         [0067]     The invention tracks the inputs from the initial customer inquiry or sales order to outbound shipments to customers by extracting data objects from the documents and notifying collaborative users of key objects. These documents are stored in the resources planning database  4448 , and the data objects comprising the elements are parsed and linked via the parts database  4446  to the physical parts used in production and output as finished goods. Materiel resource planning efforts include demand planning to determine the priority in which customer orders are filled using capacity and time constraints. Inventory planning is also a part of materiel resource planning efforts and is used to develop and implement inventory processes to meet customer demands using service targets, budgets, stock out probabilities, and cost rates. Procurement planning analysis further examines utilization of multiple suppliers to allay stock-out risks, cost variations, and single-supplier problems, and production planning focuses on deftly shifting production based upon individual product demand. Additionally, production scheduling, management of supplier networks, output requirements, packaging and storage, and equipment and facilities must all be managed properly under the production rubric requiring large numbers of documents and data objects as tools by which the processes may be managed.  
         [0068]     In the submarine example, demand planning may include the number of propellers required and the due date of the orders as well as other factors such as contractual penalties or discounts specified in the terms of the contract for late or early delivery. Additional financial factors such as tax rates on in-process inventory and other key cost elements must also be considered. An order for the propeller may include documents related to the part required, the date ordered, the date delivered, the schedule of payments, and other factors. Data objects from the purchase order, purchase confirmation, invoice, payment remittance, and other procurement papers are harvested from the documents and stored in the various databases. Data objects from these documents of particular relevance are delivered directly to the appropriate users in their native format or in a convenient format with which the user may access them.  
         [0069]     Likewise, data objects from documents related to inventory management are delivered to appropriate collaborative users to permit the enterprise to meet customer demands while aligning the timing of cash inflows and outflows to maximize their cash position. Procurement documents comprise data objects necessary to evaluate shipment accuracy, rejected goods, payment timing and are also used to evaluate suppliers, manage cash flows, and conserve financial and human capital. Further, production planning documents may be used to model production costs as well as to allocate human resource requirements.  
         [0070]     Deliver Finished Product  455   
         [0071]     Once the finished goods are produced, they are packaged and shipped to the customer. Once the propeller is completed, it is packed in a custom crate designed using data objects related to the size, weight, volume, and geometry of the propeller. The data objects regarding the size, weight, volume, and geometry of the propeller were automatically delivered by the present invention to the design engineering and shipping departments. The data objects were utilized in their native format by the shipping department so the dimensions of the propeller were known, and a suitable shipping container could be procured. Shipping orders, bills of lading, carrier regulations, and a variety of other shipping information are also stored in the resources planning database  4448 . Delivery confirmation, receipts, invoice copies, and other delivery information is also stored in the resources planning database  4448  and accessible by the collaborative team. The finished goods are then delivered to the customer to complete the sale and distribution of the product.  
         [0072]     The data objects from the shipping and delivery documents are distributed to appropriate collaborative team members. For example, sales and management personnel receive delivery confirmation objects to ensure customer delivery deadlines were met. Accounting personnel also receive data objects gleaned from the delivery documents to trigger billing activities and inventory management. Procurement personnel receive similar data objects to trigger reorder point measurements and other materiel acquisition activities.  
         [0073]     Support and Maintain Product  460   
         [0074]     Once the finished goods propeller is in the customers&#39; hands, it must be installed and supported, and installation costs, warranty costs, service costs, performance data regarding the finished goods, and customer satisfaction must be monitored. Propeller installation documents, field test measurements, regulatory compliance, and customer acceptance documents all serve to form a picture of the initial success of the product. These documents are parsed for data objects relating to the initial quality of the goods received, test performance of the finished goods, timeliness of installation, and ability of the finished goods to meet acceptance criteria. These data objects are then stored in the appropriate resources planning database  4448 , drawings database  4445 , parts database  4446 , IETM database  4447 , and requirements database  4444 .  
         [0075]     Over time, service of the propeller is required, and failure and service data generate data objects related to mean-time-between failures (MTBF), mean time to repair (MTTR), failure modes, fault tree analysis, and effects analysis. MTBF and MTTR data form a reliability picture of the propeller screw, while fault tree analysis and effects analysis may be used to predict future use availability and future performance of the propeller. Maintenance costs may be estimated using costs of materiel and labor charges to repair the propeller. Costs of operating the system may be calculated using data objects related to system availability and uptime. Spare and replacement parts inventory levels and strategies may be assessed by evaluating these data objects as well.  
         [0076]     As the product matures, on-going service may be required, and design refinements or upgrades are inevitable over the product life cycle as the product is continually evaluated during its useful life and the need for improvements and updates is realized. Secondary markets for the products may be explored, refurbishment versus replacement decisions may be evaluated, and costs of operation are continually updated by using data objects culled from service and repair history, preventive maintenance sessions, and periodic performance tests.  
         [0077]     Dispose of Product  470   
         [0078]     Once the product has reached the end of its useful life, it must be disposed, and several options such as trading the product in, re-selling the product, recycling the materials, and scrapping the product are evaluated by the customer and by the organization to determine how each of the alternatives best fits within the business rules of the organization. Data objects portraying the useful life of the product are used by the collaborators in assessing the disposal options. Acquisition cost data, depreciation schedules, replacement costs, refurbishment outlays, insurance notifications, costs of the disposal options, and other data regarding disposing of the asset are used by individual contributors in the collaborative environment to best assess disposal options and to again agree upon a consensus disposal strategy. Data objects stored in the databases are delivered to the users assist in the decision process.  
         [0079]     For example, the nature and history of the particular propeller may be evaluated to determine reliability and whether it should be accepted for a trade-in. Re-selling the propeller may be another possibility as markets may show demand for these particular systems. Likewise, scrapping the item or refurbishing the propeller also present disposal options for the organization and customer. By extracting the data elements from the relevant historic documents related to cost, performance history, and disposal options, a user may best decide and choose the appropriate disposal strategy for the particular propeller asset.  
         [0080]     After step  470 , the method for collaborative systems engineering and advanced logistics support concludes, and users and individual contributors may continue to work on additional projects.  
         [0081]     The devices and subsystems of the exemplary embodiments can communicate, for example, over a communications network, and can include any suitable servers, workstations, personal computers (PCs), laptop computers, PDAs, Internet appliances, set top boxes, modems, handheld devices, telephones, cellular telephones, wireless devices, other devices, and the like, capable of performing the processes of the disclosed exemplary embodiments. The devices and subsystems, for example, can communicate with each other using any suitable protocol and can be implemented using a general-purpose computer system, and the like. One or more interface mechanisms can be employed, for example, including Internet access, telecommunications in any suitable form, such as voice, modem, and the like, wireless communications media, and the like. Accordingly, communications networks employed can include, for example, wireless communications networks, cellular communications networks, satellite communications networks, Public Switched Telephone Networks (PSTNs), Packet Data Networks (PDNs), the Internet, intranets, hybrid communications networks, combinations thereof, and the like. In addition, the communications networks employed can be the same or different networks.  
         [0082]     As noted above, it is to be understood that the exemplary embodiments are for representative purposes, as many variations of the specific hardware used to implement the disclosed preferred embodiments are possible. For example, the functionality of the devices and the subsystems of the exemplary systems can be implemented via one or more programmed computer systems or devices. To implement such variations as well as other variations, a single computer system can be programmed to perform the special purpose functions of one or more of the devices and subsystems of the exemplary systems. On the other hand, two or more programmed computer systems or devices can be substituted for any one of the devices and subsystems of the exemplary systems. Accordingly, principles and advantages of distributed processing, such as redundancy, replication, and the like, also can be implemented, as desired, for example, to increase the robustness and performance of the exemplary embodiments.  
         [0083]     The exemplary embodiments can be used to store information relating to various processes described herein. This information can be stored in one or more memories, such as a hard disk, optical disk, magneto-optical disk, RAM, and the like, of the devices and sub-systems of the exemplary systems. One or more databases of the devices and subsystems can store the information used to implement the exemplary embodiments. The databases can be organized using data structures, such as records, tables, arrays, fields, graphs, trees, lists, and the like, included in one or more memories, such as the memories listed above.  
         [0084]     All or a portion of the exemplary embodiments can be conveniently implemented using one or more general-purpose computer systems, microprocessors, digital signal processors, micro-controllers, and the like, programmed according to the teachings of the disclosed exemplary embodiments. Appropriate software can be readily prepared by programmers of ordinary skill based on the teachings of the disclosed exemplary embodiments. In addition, the exemplary systems can be implemented by the preparation of application-specific integrated circuits or by interconnecting an appropriate network of component circuits.  
         [0085]     While the present invention have been described in connection with a number of exemplary embodiments and implementations, the present invention is not so limited but rather covers various modifications and equivalent arrangements, which fall within the purview of the appended claims.