Interactive electronic technical manual system

Military Air Land Maritime International. In SD, Separate documentation need not be done. Whatever we do in MS word will be done using sd Author software. In SD the activity is documentation. Common Source Data Base. To achieve this, the end user must have Sd CSDB server with them to host all the files received by various vendors. Reusability of data hence reduces production cost Standardization of data and naming conventions Open source and non-proprietary Good for legacy data conversion Proper documentation and version control management Zero printing cost and zero occupancies of space as no Hard copies are to be maintained.

In , the first time we received an inquiry from a Dubai-based oil and gas firm. We have also come across the sd term in various Navy documentation meetings. We picked them from LinkedIn. They were told that the project was sd, and they blindly did data entry work on the conversion of word to XML. We initially tried to develop software for Sd. It has thousands of standards of XML tags as mentioned by Sd documentation.

We have searched for an organization that is already an expert in delivering Sd solutions. After almost 6 months of evolution, we have done a technical tie-up with one of the best sd service provider companies. US-based firm We have executed projects in Sd successfully. What is this new confusion? What is fullform of IETM?

Interactive Electronic Technical Manual. IETM Viewer is software that is used to see the manuals that are converted into a database. How many Levels are in use? Why IETMs are used? How many IETM standards are in use?

Is IETM freeware or open source? All the browsers support IETM viewing. What is EXE based? How to see the IETM demo? How IETM is priced? What are the deliverables of IETM to the client? What are the files used for SD. What does CSDB stand for? What is an SD data module? What is data module code? To overcome the limitations, IETMs are designed. What is the deliverable format of IETM manual? IETM is a software where all your manuals sit. What in puts you need to make IETM? I want exploded view of our machine in IETM.

If you want exploded views, then that will be taken as content development activity. How many days will it take to develop IETM? For documents 10, to 20, it takes around 60 days. Major hindrance that we face is availability of final documents from OEM. What will be our role? I find very few IETM vendors and how different are you from others?

You can verify our Purchase Orders and approval letters. The below tables demonstrates the differences: S. Login Password Yes. But common for all. Different for all. User access All the contents will be visible to all the users.

No control over access rights to specific users. Based on login credentials, we can restrict users. Operator will be able to see only contents and PDFs and Drawings related to operator only.

Admin NO. Only single log in for all users. Admin can create and manage users and content access rights. Client can update the content. Text, images, Content tree, hyperlinks can be done using Authoring tool. Database No data base. Dash board No User Dash Board to manage user activities. Admin Dash Board to manage admin activities. Nature of content Static Dynamic.

Complete data is stored in the database. Interactivity Less More Bookmark, Annotations NO Yes. User wise bookmarks and annotations. Glossary Yes Yes Need client server environment. Dependent software's to play NO NO. Operating systems Linux Windows and Linux. User activity monitoring NO Yes.

User log in history will be tracked. Hyperlinks Yes, Hardcoded Dynamic. Each frame, Images or topic will be given a unique code. When to use When page count is up to Anywhere from to 2 lakhs. Print No Admin can print the required files.

Content Page based approach. HTML pages are developed and integrated Frame based approach. No pages exist. All data will be stored in database. Based on request from user, content will be fletched from server and displayed. Download Pdf. The style sheets can be customized to generate keys from a variety of attribute types according to the needs of the user. Furthermore, style sheets can be used to specify to the translator portion the manner in which to add the keys to a hash table index.

In various embodiments, the hash table index can comprise an internal database index. A key can comprise an identifier that serves to identify the information, such as markup language data or a tag, associated with the corresponding attribute. In various embodiments, the translator portion can be configured to generate one such identifier for every occurrence of the corresponding attribute in the input information Each such generated identifier can be included in the output information Thus, the output information generated by the translator portion can comprise one or more of the identifiers, each of which each identifiers corresponds to an occurrence of the selected attribute s in the input information , each of which identifiers identifies the information associated with the attribute in the input information , and each of which identifiers is added or inserted into the database In various embodiments, the output information can comprise keys in a hash table index.

A second style sheet can be used to specify to the translator portion the manner in which to add the keys to a hash table index. The hash table index can comprise an internal database index. In various embodiments, the database interface portion can be configured to apply an insertion instruction page to select insertion of the output information into the database as either a single document or file, or as several compressed documents or files. The database interface portion can then upload the input information for insertion into the database The input information can comprise XML formatted information.

In various embodiments, the input information can be compressed using a compression algorithm such as, for example, the java. Furthermore, in various embodiments, the translator portion can be configured to generate multiple levels of identifiers. Each level of identifiers can be hierarchically related to another one of the levels for example, the immediately preceding level or the immediately following level.

In various embodiments, a top-level identifier can serve to identify an entire input information file such as, for example, an XML file. Multiple sub-level identifiers can be provided, wherein each sub-level identifier serves to identify any XML in the input information that meets the attribute criteria specified in the applicable style sheet Further, the translator portion can be configured to index all of the identifiers, or keys, by associating each sub-level identifier with its immediately preceding for example, next highest priority sub-level identifier, and by associating each sub-level identifier with its top-level identifier.

Example input information is set forth in Table 4 below. As shown in Table 4 , the input information can comprise an XML file. Upon receiving the input information shown in Table 4, the translator portion can apply the first style sheet to generate the identifiers.

Each generated identifier is included in the output information In various embodiments, the hash table index can be stored using the hash table of the memory manager Example output information is set forth in Table 5 below. As shown in Table 5, the output information can comprise an XML file.

The hierarchically-related top-level identifiers and sub-level identifiers shown in the output information of FIG. Thus, the input information can be inserted into the database by the database interface portion in accordance with the insertion instruction page as described with respect to FIG.

After insertion into the database , the inserted document text, for example, markup language information of the input information , can be retrieved from the database using the hash table index for example, output data In various embodiments, the Middleware Tier 21 can submit a database read request comprising a specific identifier to be obtained from the database Although six keys are shown in Table 6, it is to be understood that any number of keys can be included in the hash table index.

Upon receiving the database read request, the database interface portion can search the keys in the hash table index , via table look-up or other method, for the identifier contained in the database read request.

The database interface portion can then form a database request using the sub-level identifier and top-level identifier located in the hash table index The database interface portion can then send the database request to the database In various embodiments, upon receiving the database request, the memory manager of the database can determine if the information corresponding to the identifier is contained in local memory at the memory manager If so, then the memory manager can return the information for example, XML associated with the identifier in the database request to the database interface portion , without reading the information from the storage device Because the local memory has a faster access time latency than the storage device , storing information locally using the memory manager reduces the access time to the Middleware Tier 21 to obtain the requested information.

If the requested information is not contained in memory manager local memory , then the memory manager performs a database read operation to obtain the requested information from the storage device The memory manager also can add the information read from the storage device to a hash table contained in local memory , for faster access to the information in response to subsequent requests for it.

In various embodiments, the information obtained from the database can comprise the entire file or entire amount of information associated with the top-level identifier. In various embodiments, upon receiving the information from the database , the database interface portion can forward the received information to the translator portion The translator portion can apply a third style sheet parses the information received from the database to strip out unwanted information prior to presenting or outputting the information to the client device In this case, for information flowing from the database to the client device, the information obtained from the database can comprise information input to the translator portion , and the transformed information provided to the Middleware Tier 21 can comprise information output by the translator portion Therefore, unlike other databases available for maintaining markup language information, various embodiments comprising a system and method for inserting document text into a database and for retrieving portions of the document text from that database as described herein can provide, among other things, improved speed and efficiency in indexing and searching of information as well as improved speed of information retrieval from a database, because only the desired data is transferred to the requesting device.

Further, various embodiments can be implemented using a relatively small number of instructions compared to other systems. While other databases use XPATH mechanisms to extract markup language from a database, various embodiments use unique keys created from attribute names to identify and obtain information from a database. In addition, various embodiments comprising the customized style sheets allow the user the capability to customize how information is parsed into the database and also how information is displayed to the user.

With respect to FIGS. In the example shown in FIGS. In various embodiments, the third style sheet can be a. For example, if information is stored in the database in three different languages such as, for example, English, French and German , the style sheet can cause the translator portion to obtain only the French version, if the user requested the French version and the French version is available.

For example, if information is stored in the database for different versions of a document, the style sheet can cause the translator portion to obtain the latest version. In various embodiments, the style sheets of FIGS. In various embodiments, for processing of any style sheet , elements encountered during translation that do not contain the requested attributes, or that do not match, can be returned to the Middleware Tier The method can proceed to , at which the user for example, Diagnostic Engineer 10 selects a file for database insertion.

The selection can be accomplished, for example, by entering a file identifier such as, for example, a file name, into a data entry field of an interactive page at the a remote computer of the Client Tier The interactive page can comprise an HTML page, for example. The user can cause the Client Tier 12 to send the file to the database servlet for example, the information storage and retrieval application at the Server Tier 31 via the Middleware Tier 21 by actuating a button provided on the interactive page.

Upon user actuation of the upload command or button, the Client Tier 12 can transfer the file to the database servlet, at Control can then proceed to , at which, upon receiving the input information for example, the file for database insertion , the translator portion can select the first style sheet In various embodiments, the first style sheet can be retrieved from a memory of the Server Tier 31 or using the interface Control can then proceed to , at which the translator portion can apply the first style sheet to the received input information to generate a key for each occurrence of one of the attributes to in the input information specified in the first style sheet In various embodiments, the key can comprise one or more identifiers.

Control can then proceed to , at which the translator portion can construct a hierarchy of related identifiers as the keys are generated. In various embodiments, the keys can comprise, for example, a first sub-level identifier and another identifier that is the immediately preceding level identifier to which the first sub-level identifier belongs. Control can proceed to , at which the translator portion can determine if the end of the input information has been reached for example, end of file.

If not, then control can return to to search for the next attribute in the input information selected by the first style sheet , until keys have been generated for all matching attributes found in the input information. Control can then proceed to , at which the translator portion can select the second style sheet In various embodiments, the second style sheet can be retrieved from a memory of the Server Tier 31 or using the interface Referring to FIG.

In various embodiments, the output information can comprise a hash table index Control can then proceed to , at which the translator portion can store the hash table index in memory manager local memory Control can then proceed to , at which the database interface portion can retrieve the insertion instruction page from the database Control can then proceed to , at which the database interface portion can apply the insertion instruction page to select the insertion mode for adding the input information into the database Control can proceed to , , or for insertion of the input information into the database in accordance with the insertion instruction page For example, at , the database interface portion can format the input information for insertion into the database without using any compression.

Alternatively, at , the database interface portion can format the input information for insertion into the database by performing data compression of the input information as a single document. Alternatively, at , the database interface portion can format the input information for insertion into the database by performing data compression of the input information as multiple distinct files.

For example, if the input information is received as a single ZIP file, then the database interface portion can unzip the ZIP file and insert individually each compressed file that is included in the ZIP file.

Control can then proceed to , at which the database interface portion can store in, or upload to, the database , the input information from or the compressed input information from or as either a single document or file, or as several compressed documents or files. The method can proceed to , at which the Middleware Tier 21 prepares and sends a database read request to the Server Tier In various embodiments, the Middleware Tier 21 can prepare and send the database read request in response to receiving a request for information from, for example, an application or in response to a user request received via user interface.

In various embodiments, the Middleware Tier 21 can submit the database read request comprising a specific identifier to be obtained from the database Control can then proceed to , at which, upon receiving the database read request, the database interface portion can search the keys in the hash table index , via table look-up or other method, for the identifier contained in the database read request. For example, the database interface portion can perform a table lookup of the keys in the hash table index to determine the key that corresponds to the specific identifier contained in the database read request.

Control can then proceed to , at which the database interface portion can determine if the hash table index contains keys matching the specific identifier contained in the database read request. In various embodiments, the error message can comprise an HTTP response indicating request failure. If a key is located within the hash table index, then control can then proceed to , at which the database interface portion can form a database request using the sub-level identifier, if received, and top-level identifier located in the hash table index , and then send the database request to the database Control can then proceed to , at which, upon receiving the database request, the memory manager of the database can determine if the information corresponding to the identifier is contained in local memory at the memory manager And understand how to use company products or services correctly.

That reduces product misuse, which could cause problems down the road if it is not caught in time. Something that would otherwise require significant additional planning time outside of class sessions. This allows organizations to train large numbers of students in a short amount of time and from virtually any location.

Interactive Electronic Technical Manuals help employees learn more effectively. By offering them a better way to interact with the content at hand and high-quality visuals that will hold their attention for an extended period.

There are three types of interactive electronic technical manuals:. Reference manuals typically include detailed instructions, images, and videos about how to use the product. They often include instructional animations and videos that show how to complete the task correctly. They contain rich media and multimedia content and exercises and quizzes that help users retain the information they have learned.

The information in an IETM is designed and formatted for a screen presentation that enhances comprehension. The elements of technical data making up the technical manual are interrelated such that a user's access to information within the IETM is possible by a variety of paths.

The computer-controlled IETM display device, or Portable Electronic Display Device PEDD , typically a laptop computer, operates interactively to provide procedural guidance, navigational directions and supplemental information to the end-user maintenance technician. Powerful interactive troubleshooting procedures, not possible with paper technical manuals, can be made available using the intelligent features of the PEDD. The Department of Defense generally recognizes several classes of an IETM ranging from simple non-indexed page images Class 0 to an intelligent integrated database information system Class V.

This design method allows a system designer to utilize readily available hardware and software components that meet operational intent. Diagnostic Fault Flows are described in more detail in co-pending application Ser. Thus, using the IETM of the present invention, the entire integrated system can thus be intelligently analyzed, not just individual components of the SUT. Diagnostic Fault Flows may comprise diagnostic logic needed to effectively detect and isolate faults.

In a preferred embodiment, this logic is encoded in XML. Many fault detection and isolation tasks can be predefined and stored in an XML structure, however it is possible to create an ad hoc diagnostic procedure using XML. In a typical 3-tier application, the application user's computer client tier contains the programming that provides the graphical user interface and application-specific entry forms or interactive windows. The server tier includes a system level database and a program to manage access to it.

The middleware tier contains logic for acting as a server for client tier requests from application users. In turn, it determines what data is needed and where it is located and acts as a client in relation to the server tier. Using the flexible N-tier architecture described herein, the Class V IETM of the present invention provides effective fault detection and isolation using automated interaction with the SUT.

Furthermore, embodiments can comprise a system and method for inserting document text into a database and for retrieving portions of the document text from that database. In particular, various embodiments can comprise a system and methods for generating one or more keys from selected attributes occurring in input information, and to insert output information comprising the keys into a database.

In one embodiment of the present invention, the system is deployed as a standalone program on the maintenance technician's PEDD. In this embodiment, all of the tiers client, middleware and server are distributed within the PEDD. In another embodiment, the client tier is distributed on the PEDD and the server tier is distributed on a network server. In this network-centric embodiment, many PEDDs could connect to the network server.

Many different configurations will be apparent to one skilled in the art. The server tier may be comprised of a database application. In a network-centric configuration, the database application is running on a network server supporting a plurality of PEDDs.

The server tier does not necessarily have to run on a separate server computer, however. For example, in one embodiment, the server tier may be a separate software process executing on the same computer as the middleware tier. These XML-encoded structures are stored by and accessed through the Server Tier database application. All communication in the IETM of the present invention is routed through the middleware tier.

The middleware tier of the present invention may be implemented using Java 2 Enterprise Environment J2EE servlet technology. In a standalone configuration, the middleware tier is distributed on the PEDD, along with the server tier and the client tier.

In a network-centric configuration, the middleware tier may reside on any computer in the network. As mentioned above, in one embodiment the middleware tier is logically distributed between a PEDD and a network server. In this embodiment, the middleware tier is logically divided into two components, one resident on a PEDD and one distributed on the network server.

The client tier may be implemented as a Java application operating on a maintenance technician's PEDD.

In addition, the Java application includes a set of HTML web pages that may be accessed by geographically remote Diagnostic Engineers, discussed below.

For example, during execution of a Diagnostic Fault Isolation Task, it is possible that a situation may be encountered wherein the pre-stored Diagnostic Fault Isolation Tasks cannot properly diagnose the problem. In these situations, the maintenance technician may require additional assistance to diagnose the problem.

Alternatively or in addition to Help Desk assistance, the maintenance technician could email fault logs, capture screenshots, or send other information to technical assistance personnel. This is shown in FIG. The present invention allows Diagnostic Engineers located remotely from the maintenance technician and the SUT to interact directly with the IETM, and thereby indirectly with the SUT, in order to assist the maintenance technician.

This Remote Maintenance Assistance feature of the IETM of the present invention is preferably implemented through the N-tier architecture described above. This access can be through a Java Servlet request, for example. However, if a maintenance task requires the physical activation of a button, the local maintenance technician must perform that operation. In particular, the three tiers of the n-tier architecture of the present invention are a client tier 12 , a middleware tier 21 and a server tier In the example shown in FIG.

Predefined tasks are stored in the server tier database. The request is customized to request an external identifier xrefid. The xrefid is the identifier of the database-resident task to be executed on the PEDD. The example shown in FIG. It will be apparent to those skilled in the art that alternative configurations are possible.

In this configuration, the server tier software component and the middleware tier software component may operate as separate processes running on the PEDD. During the processing, the optional parameters are parsed, which may result in additional constraints levied on the XML returned from the Server Tier database application As shown in FIG.

SUT 60 responds to the client tier 12 with the requested information in communication The requested SUT procedures are typically BIT procedures, and the XML-encoded diagnostic process may contain multiple BIT procedures, so communications and may occur several times for a single process request.

The middleware tier 21 waits for a response from the client tier application 12 that indicates the results of the entire diagnostic process. This result is forwarded to the remote Diagnostic Engineer in communication As mentioned above, the Remote Maintenance Assistance feature of the present invention may invoke a pre-stored task or an ad hoc task.

When invoking a pre-stored task, the Middleware servlet interprets the HTTP request that includes the identifier of the database-resident task, as described above. In contrast, ad hoc tasks may be directly requested through well-formed XML that contains specific instructions to initiate the task to be executed remotely. In this ad hoc task-processing configuration, it may be possible that the system will not check XML syntax in a request, and it is therefore the Diagnostic Engineer's responsibility to ensure that the proper XML structure is adhered to.

IETMs are typically stand-alone applications that the maintenance technician uses during the execution of maintenance actions. The hybrid configuration allows the maintenance technician to continue working even if the network is unreliable.

The IETM of the present invention allows many different configurations and the flexibility to work in many different communications environments. The In-Sync feature of the present invention allows for a hybrid configuration. The servlet ensures that any downloaded files are copied to the correct location on the PEDD. Preferably, version information of downloaded files is also stored on the PEDD.

Downloading updated files allows the IETM of the present invention to operate in the hybrid mode. The In-Sync feature also allows for uploads. The In-Sync feature may also initiate any needed special processing, such as placing a file in a certain location or indicating a system command to be performed. The In-Sync operation is automated and customizable. Updates to the maintenance technician PEDD data and applications can be scheduled. Alternatively, updates can be configured to occur on a cyclical schedule.

Remote machine 10 could be a Diagnostic Engineer's computer for example. Alternatively, remote machine 10 could be a network server. Typically, there are three different types of files that are downloaded to a PEDD in a request. First, support files that assist in loading of the Server Tier database can be downloaded. Second, data files that are loaded into and managed by the Server Tier database can be downloaded.

Third, application executable files can be downloaded. If the IETM application executables are being updated to a new version, this can be accomplished through block In the present invention data displayed by the application can be controlled dynamically. In addition, this feature allows the support information to be displayed in multiple languages. For example, a SUT may contain many components that can potentially have many versions of interface software. The present invention may use an eXtensible Stylesheet Language XSL filtering process to allow for dynamic visualization and filtering of data.

XSL gives a developer the tools to describe exactly which data fields in an XML file to display and exactly where and how to display them. In the present invention, the manuals and technical data used in the Dynamic Diagnostics process are in the form of XML.

By using an XSL filtering process, separate databases are not necessary to control version information. Keys can be used to identify each version's unique data. The XSL translation uses the key to only pull the data that is unique to that key.

In addition, the XSL translation can pull data that does not have a key. This data is considered to be common to all versions. Table 2 illustrates an example that uses keys to identify a version 1 and a version 2 of the graphic. If no key is used, all data requested would be received i. Instead of having multiple databases for each supported language and maintaining each database, one database can be used with keys to identify the desired language.

A key similar to version control is used to perform XSL filtering for language. Each supported language has a key to identify the language within the XML. If the data does not contain a language key, it is considered common data and is shown in all languages. As shown by FIG. This is a significant advantage as XML in its native format is not printer-friendly, as shown by With respect to FIG.

In various embodiments, the Server Tier database application 31 can comprise an information storage and retrieval portion provided in communication with the Server Tier database The Server Tier database application 31 can further comprise a communication interface configured to accomplish packet-based communication using the interfaces and In various embodiments, the information storage and retrieval portion can comprise one or more servlets that includes a sequence of programmed instructions that, when executed by a processor, cause the processor to be configured to perform database insertion and retrieval functions as described herein.

The Server Tier database can comprise a memory manager and a storage device provided in communication with the memory manager In various embodiments, the Server Tier database can store and retrieve information or data in response to one or more Structured Query Language SQL instructions. The storage device can comprise a hard disk drive configured to store information in accordance with SQL. Further, the memory manager can comprise a database manager that includes a local memory In various embodiments, the memory manager local memory can comprise a hash table index and recently accessed database information from the storage device In various embodiments, the local memory of the memory manager can have a faster access time latency than the storage device For example, the local memory can comprise a Random Access Memory RAM and the storage device can comprise a hard disk drive, in which case the local memory can have an access time latency on the order of ten times faster than the storage device In various embodiments, the local memory can comprise a fixed memory size specified by a target threshold size parameter.