Bernhard Weichel | |
Section Manager | |
Robert Bosch GmbH | |
bernhard.weichel@pcm.bosch.de |
SGML/XML - as glue in
engineering processes
Outline
Engineering processes for engine management systems | |
A flexible document architecture | |
The document base as a glue layer | |
Case study: The document base in the MSR consortium | |
Conclusion |
SGML/XML - as glue in
engineering processes
Phases in the engineering process
SGML/XML - as glue in engineering processes System design tool
SGML/XML - as glue in
engineering processes
Document layer architecture
SGML/XML - as glue in
engineering processes
Document base as a glue layer
generate required view using one single tool set regardless of the source of data | ||
standardized data format | ||
overcomes proprietary formats | ||
use for long term archiving | ||
data remains useable even if the creating tool disappears | ||
life time of data much longer than life time of computersystems | ||
integrate results of different engineering groups | ||
using different tools |
Building the document
base
The role of the DTD
The DTD is the contract how to find data in the document base | |||
Major DTD types: | |||
Layout oriented DTD | |||
focus on redition | |||
oriented on capabilities of publishing tools | |||
suitable for layout oriented document base | |||
Presentation oriented DTD | |||
focus on presentation structures | |||
flexible layout on different media | |||
appropriate for presentation oriented document base | |||
Database oriented DTD | |||
representing data models | |||
essential for data exchange on all levels | |||
The character of the required DTDs is determined by the objectives on the document base |
Database oriented
DTD
Relational data model
Easy to implement | ||
normalized data model | ||
can use attributes | ||
relationships by reference | ||
Useful | ||
archiving | ||
import/export format |
Database oriented
DTD
Object oriented model
tree structure | ||
one to one and one to many relationships | ||
objects grouped in container | ||
express relationship directly | ||
implicit acess path to the data | ||
multiple relationships | ||
links of specific semantics | ||
occurance operator | ||
allow various instances matching one DTD |
||
useful for subclassing | ||
Inheritance | ||
by reference | ||
by position |
Using a database oriented
DTD
Supporting the entire process
Information content is different across the process phases | ||
many flavours of instances (as much as we have process steps?) | ||
occurance cannot finally be checked by SGML/XML parser | ||
Different data is generated in different process steps | ||
sophisticated version control and process management | ||
tools to merge data | ||
Not all objects exist along the process chain | ||
handle broken links | ||
establish links automatically by knowing the semantics | ||
convert to standard SGML style for exchange | ||
Global data models of tools or processes must be mappeded | ||
export capabilities are determined by the internal data model | ||
allow multiple global data models | ||
harmonize data models on SGML level |
Using a database oriented
DTD
Supporting the entire life cycle
Using a database oriented
DTD
Use one DTD across the entire process!
Benefits | ||
latter steps can be performed on preliminary results (e.g. formatters for presentation view) | ||
using the same filters in multiple process phases | ||
unique and constant data access path througout the process | ||
improvements in the process do not require new DTD | ||
only one DTD to manage | ||
Drawbacks | ||
data model for each process phase must be defined outside of the DTD |
||
actually no formal method available |
Using a database oriented
DTD
Approaches for processing
Source driven | ||
sequence and selection of processing determined by the instance | ||
all information in the source must be handled | ||
Target driven | ||
sequence and selection of processing is determined by the desired results | ||
Information from multiple locations in the instance can be processed at once | ||
Existing instances can be enhanced during the process while leaving unknown data untouched |
Using a database oriented
DTD
Query language requirements
querying multiple instances simultaneously | |
accessing any information in the instance in any order | |
cascading queries | |
applying any condition at any point | |
keep results of subqueries for later use | |
combining results of queries such as union, intersection etc. | |
result of the query can be anything from single value to an entire tree | |
optimizing performance by introducing auxilliary data structures |
Using a database oriented
DTD
Example: finding invalid parameters
Using a database oriented
DTD
Example: merging data
Using a database oriented
DTD
Authoring in SGML/XML directly
Instances for database oriented DTDs should not be edited manually | ||
Nevertheless, manual editing may be necessary | ||
prototyping | ||
debugging | ||
no generator available | ||
basic functionality in SGML editor
makes it possible |
||
this is still not ideal | ||
link Manager | ||
templates for objects |
Using a database oriented
DTD
Link manager
Show link types | ||
Show link targets | ||
Search link targets | ||
Navigate in the instance | ||
Link preview | ||
inspect al references | ||
Establish links | ||
Handle broken links | ||
load external targets | ||
Check links |
Using a database oriented
DTD
Templates
Provide supported classes as templates | |
Identifiy an appropriate insertion point | |
define templates on the fly |
Using a database oriented
DTD
Recommendations and experiences
define the data model as completely as possible | ||
compromises must be fixed later with much more effort | ||
define the semantics as strictly as possible (how ???) | ||
elements are better to handle than attributes if authoring is done in SGML | ||
SGML’s datatyping is not sufficient | ||
implement your own based on architecture attributes | ||
try to establish linking based on existing data | ||
it is not always necessary to follow the link | ||
use synergy of natural object identifiers (e.g. object names) | ||
keep flexible in the global data model (locations of containers) | ||
this makes it easier to adapt on existing tools | ||
be aware that the files tend to be big
(10 - 15 Megabytes): “terseness is not a design goal for XML (Tim Bray)” |
SGML/XML - as glue in engineering processes Document base defined in MSR/MEDOC
MSRSYS database oriented DTD to specify entire control systems | |
MSRNET database oriented DTD to support development of vehicle networks | |
MSRSW database oriented DTD to support development of Software for electronic control units | |
MSRFMEA database oriented DTD to support Failure Mode and Effect Analysis | |
MSRREP Presentation oriented DTD to support arbitrary reports |
SGML/XML - as glue in engineering processes Conclusion
SGML/xml offers great potential to establish a glue layer in complex engineering processes | |
care must be taken on DTD design | |
powerful query language and middleware is required | |
MSR provides public available DTDs for engineering of electronic systems in the automotive industry | |
database style of DTDs is possible but
not yet in the mainstream focus of SGML/XML this is to be changed! |
|
it is my intention to contribute to
this process and to encourage others to using the potential provided by SGML/XML |
|
Thank you |