Practical use of XML in Healthcare applications   Table of contents   Indexes   Active Schematics - a new approach to publishing complex schematic information electronically
 

Producing and using intelligent graphics in XML/SGML electronic publishing
 Michel   Gaudron
  Sogitec Industries  4, rue Marcel Monge
 92158 SURESNES   France
Email: gaudron@sogitec.fr
Phone: (33) 1 41 18 56 93
Fax: (33) 1 41 18 56 49
 
Biographical notice:
 
Michel Gaudron is a Software Project Manager in the Communication Division of Sogitec Industries SA since 1995. He is in charge of the development of the ViewTec electronic publishing product and of the related application projects : Dassault Aviation Falcon business jets maintenance documentation, Dassault Aviation Rafale and Mirage 2000 fighters maintenance documentation, etc.
 
Previously, he worked at Jouve and has been involved in electronic publishing products since 1990.
 

Introduction
 intelligent graphics 
virtual factory
 
Today's technical publication environment is driven by the quick evolution of industrial information systems towards thevirtual factory . The kernel of the virtual factory may be seen as a large repository of digital data managed in configuration, that can be accessed by all the members of a given project: designers, logistic support analysts, manufacturers, technical writers, sub-contractors, customer support teams, etc.
 
Because the logistic support is becoming an important part of the product, the technical publishing activity must be able to take advantage of thevirtual factory . This new situation is mainly due to the customer oriented approach taken by industrials.
 
The technologies available at the present time for technical publishing permit the creation of sophisticated tools for maintenance, trouble-shooting and procurement activities. These tools must be produced according to the same standards and constraints as those used for designing and manufacturing the supported system. They must therefore use the source information stored in the common repository to follow the life cycle of the system. Concurrent engineering requires that the documentation production tasks as well as the design and manufacturing activities be monitored by the configuration manager.
 
The repository contains digital data objects that are useful as source data for technical publishing. These objects are 2D or 3D representations of the parts that compose the overall system and result from designing and manufacturing activities. These objects must be considered as the reference source data for intelligent graphics and models that are needed for creating sophisticated electronic technical documentation.
 
In that context, we will discuss the multiple issues that must be addressed when dealing with intelligent graphics in electronic technical documentation.
 
Our goals are to :
 
  •  Produce the documentation with industrial constraints (cost, accuracy, etc.).
  •  Target standard computer hardware and software for viewing.
  •  Distribute the documentation both on Intranet/Internet and on CD-ROM.
 
We will consider the following points :
 
  •  Editing intelligent 2D drawings such as Wiring Diagrams.
  •  Editing intelligent 3D models such as Illustrated Parts Catalog figures.
  •  Choosing the publishing format for these graphics or models.
  •  ‘Screen writing’ the documentation (Maintenance Documentation, Descriptive Documentation, etc.) using the intelligent graphics and models previously created.
 

Editing intelligent 2D graphics
 
Why do we need such intelligent graphics ?
 
Because we want to offer to the technical documentation users the following functionalities:
 
  •  intelligent navigation from and to illustrations,
  •  object animation,
  •  object meta-information.
 
To illustrate the points listed above let us chose the ‘Wiring Data’ example.
 
See illustration below.

Wiring Diagram example


The Wiring Diagram objects have been redlined.

  
 
  •  Navigation based on the wiring (from one equipment to another one) allows movement both inside a wiring diagram and outside to a wiring list or another wiring diagram.
  •  A wire can be animated (blink, colour) to enhance its visibility among a large amount of graphic data (the typical size ranges from double A3 to A1 formats).
  •  Meta-information composed of : equipment/component ID, connector ID, pin ID, wire ID, various P/N, etc. can be contextually displayed by the browser (screen tip).
CAD/CAM
 CGM, Computer Graphics Metafile 
 STEP  
standard exchange formats
 

2D Graphics trends
 
In order to get a good level of genericity, it is obvious that we must use standard formats for exchange.
 
There are two technologies that may be used alone or combined :
 
  •  First use a standard CAD/CAM export format like  STEP  (STandard for Exchange of Product model data) .

    Note:


    STEP is an ISO standard for the sharing and exchange of product data. It is used by CAD/CAM applications to exchange models.
  •  Second use a standard 2D format that could contain the information like CGM Version 4 (Computer Graphic Metafile) or  SVG  (Scalable Vector Graphics) .
 
In the first case (STEP), we get all the information required but we also get a lot of information that is not useful. This means that the transfer of information to the user will be strongly penalised either by transfer time or disk space. The viewing application must parse the entire flow before displaying anything and approaches the complexity of a full CAD/CAM application.
 
In the second case, the information must be propagated in ‘application data’ structures. The information can be automatically inserted by a specific application that may be seen as an intelligent filter.
 
Because there is no mature STEP viewing technology and because both Internet bandwidth and CD-ROM space are limited, only the second type of solution sounds reasonable today.
 
Because of the unstable nature of SVG as a working draft specification, we will develop only a solution based on CGM. However the concepts are promising and it is important to follow the proposed W3C standards. A brief description of the SVG format is given further.
 

CGM Version 4
 
Version 4 of the CGM standard defines the notion of Application Structure (APS) that may be used for implementing some of the targeted ‘intelligent’ features.
 
An application structure (APS) is used to group graphical primitives in a picture together and assign certain attributes to the group. The object is geometrically identified by the set of primitives enclosed between the BEGIN APS and END APS elements. APSs may contain any CGM graphical content allowed by the profile, and may contain other APS and APS attribute content.
 
The various experiments implemented by the CGM vendors show that this approach is promising but at the same time raises interoperability issues .

Note:


A given CGM browser was only able to play APSs that were written by a CGM authoring tool from the same vendor.
 
To facilitate the interoperability, there are two initiatives : ATA Intelligent Graphics Exchange and WebCGM.
ATA Intelligent Graphics Exchange
 

ATA Intelligent Graphics Exchange
 
The ATA Graphics Exchange Specification (GREXCHANGE) defines a way to standardise the exchange of meta-data using APS. However, the behaviour is not specified and must be implemented in CGM browsers.
 
At a certain level, a CGM V4 meta-file may be seen like an SGML instance. It is thus possible to implement the same hyperlinking mechanisms as in SGML documents.
 WebCGM  
 

WebCGM
 
The CGM Open consortium and the W3C have developed the WebCGM Technical Recommendation.
 
Briefly exposed, the WebCGM TR is a CGM profile that enables the following features:
 
  •  Two way linking (uses the URI syntax).
  •  Layered pictures.
  •  Text search.
 
The WebCGM is derived from the ATA Profile : this implies that CGM tools conforming to the ATA profile could be used for the WebCGM profile.
 

Typical Industrial process (Wiring Data example)
 
The whole wiring data is available in CAD/CAM format and has been validated. Only the wiring data that are applicable to a plane (or range of planes) are to be processed.
 
The process will consist in:
 
  1.  Exporting the drawing in CGM primitives.
  2.  Grouping the primitives in OBJECTS ( may be done in a specific layer).
  3.  Associating meta-data to OBJECTS.
 
The third step requires an export specification that indicates what data has to be extracted from the CAD/CAM database. All steps are automated and use scripts to run. There is no manual intervention except for control.
 

Using WebCGM Profile with Wiring Data example
 
A Wiring Diagram can be described in terms of embedded objects. These objects are a graphic representation of wiring objects: equipments, connectors, pins and wires.
 
Each object can be declared as a GROBJECT and can contain the following attributes:
 
  •  ID = unique identifier for the object ( this ID will be used for navigation to this object)
  •  NAME = string that subtypes the object (PIN, CONNECTOR, WIRE, EQUIPMENT, etc.)
  •  SCREENTIP = caption of the tip (external ID for the object)
  •  LINKURL = URL string ( useful if the object is a link to another WD)
 
The GROBJECT declaration delimits also the CGM graphic primitives set that will be rendered on the screen or the printed page.
 
It is also possible to use LAYER objects to separate different representation of the same object. Object animation can be obtained using activation of the different layers.
 
Each object may contain other child objects that can be used to store information such as P/N, MFR code, etc. :
 
  •  PARA
  •  SUBPARA
 
Note, that this APS information may be inserted in several layers so you may upgrade legacy drawings (i.e. CGM of a version lesser than 4, raster) .
 style sheet  
style specification
 

Styles, please!
 
A further analysis of the ATA and WebCGM profiles shows that it would be powerful to use the conjunction of the embedded SGML tree (APS play the role of an SGML element) with an associated style specification. Ideally this style sheet would be written in DSSSL or XSL and would contain mostly behaviour like conditional link traversal, animation, etc. The separation between content and presentation has been successful for SGML, there is no reason to ignore this major benefit. You may desire different presentations for the same drawing depending on the calling point in your documentation. For instance, it may be powerful to reuse IPC graphics in AMM (Aircraft Maintenance Manual) procedures.
 

SVG
 
SVG (Scalable Vector Graphics) is a specification from the W3C based on XML, DOM and CSS.
 
SVG is a language for describing two-dimensional graphics in XML. SVG allows for three types of graphic objects: vector graphic shapes, images and text. Graphical objects can be grouped, styled, transformed and composited into previously rendered objects.
 
SVG drawings can be dynamic and interactive. The Document Object Model (DOM) for SVG allows for straightforward and efficient vector graphics animation via scripting.
 
SVG can store private data in the graphic contents.
 
SVG status is ‘working draft’ and is backed by Adobe, Corel , Microsoft and many others.
 
However, given the fact that SVG is the third vector graphics format proposed to the W3C in the past year, this approach is currently too unstable to serve as a basis for industrial processes.
digitial mock-up
 

Towards 3D models
 
As previously exposed in the introduction, 3D models are stored in thevirtual factory repository. At the same time, 3D viewing technology is available at low cost on standard computers.
 
The 3D source information is also retrieved from CAD/CAM systems, but we must cope with what is called adigital mock-up of the system to be documented.
 

What is a digital mock-up?
 
This a digital representation produced from thevirtual factory database that mainly consists of:
 
  •  A tree representation (node and branch) of the system managed in configuration.
  •  A repository of data objects that represent each part of the system (node) and can contain 3D models.
  •  The constraints between 3D models data objets: positioning , assembly rules, etc.
 
The digital mock-up uses the geometry of assembled objets (properties) to build a virtual prototype that can be manipulated like a real one. You may explore, disassemble, put in motion, stress the prototype.
 
The digital mock-up for support documentation will require specific information about the maintained system : specific support system breakdown, disassembly structure, etc.
 
Today's available technology is not able to give a true digital mock-up access to maintenance documentation users. However, it is possible to publish specific 2D views or 3D models for maintenance documentation purposes from the original digital mock-up.
 
Other considerations may lead to filter the information delivered to end users : industrial confidentiality, user configuration applicability, etc.
 

Using the digital mock-up
 
The 2D views and 3D models are built during a digital mock-up session that consists in :
 
  •  Building a query by pre-selecting the models to be used.
  •  Sending the query to the mock-up.
  •  Getting a 3D assembly of the selected models.

A digital mock-up session


Flow chart.

  
 
The session parameters may be saved when the view has been validated by the graphical author: point of view, assembly/disassembly state, etc.
 
This session specification is an important added value that must not be underestimated when designing technical documentation. Moreover, it is to be considered as an asset, because it can be reusable when the system evolves.
 
The digital mock-up is the main source data and the evolutions made to the system can induce the documentation changes.
 meta-data 
 

Editing 2D graphics from 3D models
 
The digital mock-up can be efficiently used to edit 2D drawings from 3D models.
 
The process will consist in :
 
  1.  Building a session (or using an existing one).
  2.  Getting a 3D model assembly.
  3.  Using the generated 2D view, creating an information layer to associate meta-data to models (callout, captions).
  4.  Converting the model to a 2D exchange format : CGM meta-file.
 
The fourth step includes the merging of the information layer in the 2D file.
 
Note that the information layer is reusable when the system evolves. Remember! The recipe to build the drawing = digital mock-up + virtual factory repository query + information layer.

3D model assembly


Screen capture of a digital mock-up session.

  

2D view of the 3D model assembly


Result drawing.

  
 

Editing intelligent 3D models
 
Why do we need such 3D models in technical documentation?
 
Because we want to offer to the technical documentation users the following functionalities:
 
  •  Intelligent navigation from and to 3D models.
  •  Object animation : explore, disassemble parts, put in motion, etc.
  •  Object meta-information : the same as for 2D plus, others like geometry, physical properties, etc.
 VRML  
exchange format
virtual world
 

3D Exchange format
 
We face a similar situation as for the 2D case and again, in order to get a good level of genericity, it is obvious that we must use stabilised standards for exchange.
 
There are two technologies that may be used:
 
  •  First use a standard CAD/CAM export format like STEP.
  •  Second use a standard 3D format that could contain the information like VRML  (Virtual Reality Modeling Language)
 
VRML (ISO/IEC 14772) , defines a file format that integrates 3D graphics and multimedia in a virtual world .
 
In a VRML world, meta-information can be stored using the following architecture:
 
  •  Node = object.
  •  Field = property of a node or object.
  •  Event = event can be associated to a node or a field ( event in or event out).
 
Scripting is possible using either Java or ECMAScript (standardised version of JavaScript) and can be used to access objects from outside or in association with an event.
 
For the same considerations as in the 2D discussion, VRML as an international standard looks as the perfect candidate.
 
This enthusiasm has to be tempered because the available technology applied to complex system (like aircraft) is not usable with today's standard computers.
 
To give just an idea, we extract from the CAD/CAM data some elementary component like a ‘fuel transfer pump’ or a ‘landing gear door’. These components can be considered as simple relative to the whole aircraft. The VRML files produced by the standard export filter weighs several Mbytes, resulting, at the user level, in loading time in the magnitude of tens of seconds. Because of space and bandwidth considerations, it is simply not usable for the current time.
 
However, we must consider this situation as temporary because the PC power and software will surely make it possible soon.
 

The industrial process
 
The process is very similar to the one used in the 2D case.
 
The process will consist in :
 
  1.  Building a session (or using an existing one)
  2.  Getting a 3D model assembly.
  3.  Getting meta-data from thevirtual factory repository.
  4.  Converting the model to a 3D model exchange format.
 
In the second step, the exported 3D models are a projection of a specific part to be documented and include the information we will need later: different indexed positions, disassembly sequences, etc.
 
The third step could be a query sent to the database using the information stored in the digital mock-up.
 
The fourth step includes the merging of the meta-data obtained from the repository.
screen writing
 

Screen Writing issues
 
Screen Writing is the basic process for creating a multimedia title with an authoring tool like Macromedia Director. Basically, this kind of tool enables the multimedia creator to select actors (objects), put them on a stage, give them a scenario (behaviours) and make them play (events).
 
Once the 2D and 3D intelligent graphics have been prepared, they must be used in the technical documentation as actors.
 

Interactive process
 
The interactive process must be used when the source document (SGML document for instance) is authored by a technical writer. The author must interactively specify the behaviour for the graphics.
 
The interactive screen writing tool must be able to understand the standard formats exposed above in order toconnect the XML/SGML text with the intelligent graphics.
 
The simplest example : connect a callout in a graphic with the reference to it in the text.
 
A more complex one : connect a reference to a disassembly sequence found in a maintenance procedure to the animated sequence in a 3D model.
 
The main difference between a multimedia title and technical documentation using these techniques lays in the revision management. A multimedia title is written once and probably will never be updated.
 
In the domain of technical publishing, the screen writing must be reusable even if objects have changed : for example, the callout position has been changed but it still exists or the disassembly sequence has been updated by the graphics editor.
 
The screen writing environment must provide convenient means for selecting the proper graphic object, getting information from it (introspection in the object-oriented programming sense), linking correctly to it and from it. The exact requirements will depend on the degree of interaction needed or enabled by the viewing technology: display, highlight a specific part, start an animation, etc.
 

Automated process
 
The automated process can be used when the calling document (automatically generated after a database extraction) holds enough information to specify the graphic behaviour.
 
When the meta-information is stored in both intelligent graphics and SGML instances, it is easy to use it for linking documents. The linking process can be automated with all of the usual advantages : increased speed, reduced costs, improved reliability, etc.
 
Each object in a given graphic holds one or several keys (IDs) that may be put in relation with the corresponding reference (REFID) found in the SGML text. The reverse situation is handled symmetrically.
 
For instance, the Illustrated Parts Catalog and the Wiring Manual can be processed by an automated linking process :
 
  •  IPC graphiccallouts are linked to their corresponding CSN in the part list,
  •  Wiring Data items such as Equipment, Connector, Pin, Wire are linked to their counterpart in the wiring list.
 hyperlink 
 navigation 
 

Navigational issues
 
Navigation is a fundamental requirement when dealing with interactive documents. However, navigation requirements are handled in various forms depending on the standard used.
 
We will discuss briefly the graphic navigation aspect in the available pointer / link specifications.
 

Xpointer/ Xlink
 
The Xpointer specification has no specific provision for graphical navigation because it is mainly dealing with an XML documents navigation. If you want to address a graphical hotspot, you must use a meta DTD with dedicated tags (like Synex Viewport meta DTD).
 

HyTime
 
HyTime does have such provision, but there is no software (to my knowledge) that implements it.
 

WebCGM
 
The WebCGM uses the URI syntax to specify links.
 
The URI fragment appended to the base URI defines the picture, object, and the desired viewer behaviour. The URI fragment syntax is based on concepts described in the XML Pointer Language (Xpointer).
 

VRML
 
From any VRML object, the navigational features use either the URL or URN syntax.
 
The URN (Universal Resource Name) defines a web persistent naming convention. URNs may be used now as persistent unique identifiers for referenced entities.
 
Access to VRML objects is possible through a scripting language (though ECMAScript and JAVA implementations are described, other languages may also be used).
 

Uniform linking machinery
 
We need at least the same navigation capabilities as in textual information. In other terms, the linking machinery must not know much about the object's internal representation. For instance a HyTime link based on a CLINK / NAMELOC construct makes no assumption about the targeted document's DTD. The fundamental hypothesis is that the targeted ID must exist in the document.
 
One possible solution:
 
  •  The graphic must be seen as a grove with navigational properties, or expose a DOM API to internal objects. The grove must be built by the graphic display component.
  •  The linking information must be coded either in Xpointer/Xlink or HyTime format.
 
In that solution the navigational engine (the software component that solves the links) will behave the same for intelligent graphics as for XML/SGML documents.
 

Conclusion
 
The emerging standards (like CGM V4 and profiles, VRML) in the field of intelligent graphics and models are the basis of the next generation of electronic technical documentation elaborated with other standards (SGML/XML, STEP).
 
Intelligent graphics and models can be the result of the transformation of 2D and 3D objects stored in thevirtual factory repository.
 
The technologies (though not entirely optimised for standard desktop machines) are present and some are already operational.
 
It is (or will be soon) possible to create intelligent graphics on an industrial scale at competitive costs.
 
There is an important added value in using intelligent graphics :
 
  •  first in the creation process to select the pertinent information in the repository,
  •  second in the screen writing process to use it in the documentation.
 
Tomorrow's electronic technical documentation will use a mix of technologies supporting the above mentioned standards and will permit:
 
  •  Online access tovirtual factory stored views.
  •  Offline access tovirtual factory published views with periodical information update.
  •  Automated adaptation to customer configuration.
 
Bibliography
ATA Specification 2100 Digital Data Standards for Aircraft Support Revision 4 March 98 - Intelligent Graphics Exchange IGEXV2.4.
Scalable Vector Graphics (SVG) Specification W3C Working Draft 11-February-1999 (http://www.w3.org/TR/WD-SVG/)
ISO/IEC 14772-1:1997 Virtual Reality Modeling Language (VRML97) (http://www.vrml.org/Specifications/VRML97)
A white paper on the state-of-the-art of 3D CAD in an Internet/intranet-based world, Ulrich Sendler, October 1998.
Real Time, Regis McKenna, Harvard Business School Press, 1997
Practical use of XML in Healthcare applications   Table of contents   Indexes   Active Schematics - a new approach to publishing complex schematic information electronically