Strategies for implementing SGML/XML as a glue layer in engineering processes

automotive  embedded system engine management

Engine management systems for modern cars are very complex ( ). They collect characteristical data like speed, load, various temperatures etc. from the engine and control the engine performance with respect to various optimization criteria. In addition to this other function like on board diagnosis, security etc. must be provided.

Motronic ME7

engineering  engineering process  process

The engineering process for such complex systems covers multiple phases ( ) handled by many different people. These participants in the process are using various engineering tools to produce results appropriate to their process phase but also for the entire process. The problem is, that each sub process requires a set of documents and data which is not necessarily known by the other participants. This often leads to individual data files, documents and data formats where the data are captured many times.

Phases in the engineering process

System development

system design system simulator

Development of systems with complete programs built of functions from an existing library as well as new functions which are defined as specification for the function development. In addition to this, system development covers areas others than software (but which may influence software).

Function development

This discipline defines new functions performed in theECU to control the engine. The function development is based rather on generic principles than on individual engines or implementations. Therefore this tasks is usually performed using control simulation tools where functions are defined using block diagrams, state machines etc. An example for this is given in

Software development

The functions are coded for the individual target platform. Although actually coding is a manual task, we will see more and more code produced by code generators built into the simulation tools which are fed by all the required information.

System configuration

The developed functions are integrated into complete systems. This is done by creating build descriptions, project configuration files etc. One of the software variants is built using about 250 out of 500 available functions.

Calibration

The entire system is applied to a certain engine type (variant). In this phase all of the about 3000 calibration parameters in the system are adjusted to match the performance objectives for the actual engine variant. In order to perform this calibration a detailed documentation as well as appropriate tool support is required. The basic information set for this task is created in the phases mentioned above.

Function development in ASCET simulator

document

While dealing with such complex engineering processes, it is often unclear what a document really is. The three layer architecture in can help in this respect:

Document layer architecture

Presentation view

HTML, Hypertext Markup Language  presentation view  rendition  selection

This is the daily experience with a document. It is a piece of paper with a certain amount of information which is presented using various fonts, layouts and graphical elements. Progressive people use this document in electronic form.

The main focus of this layer is to present the right set of information in an appropriate layout. Therefore it is the primary domain of typewriters, word processors and electronic distribution media. I would even position HTML in this layer.

Engineering Base

data management engineering tool

The engineering base is the set of engineering data in the original formats of the tools used in the process. These data files are usually stored in an EDMS  (engineering data management system) which has no access to the content of the administrated data.

Nowadays engineering tools produce document views using report generators or interfaces to common word processors often proudly marketed as "documentation interface". In a broader sense, the information in the engineering base itself and not only the exported presentations must be treated as documents.

If views are required which reflect information from more than one engineering tool, then either some connection of the tools is required, or the documents must be assembled manually.

Obviously there is a gap between the presentation view and the engineering base.

Document Base

archive  document instance

The existing gap between the two layers mentioned above can be closed by introducing a middle layer, the document base. This layer must be built upon a standard data format which can be used to generate all the required outputs (document views) in the presentation layer while still having the power to keep the semantics of the engineering base at least to some extent.

This layer is the domain of SGML/XML, which is easy to create, able to define powerful data structures and not too hard to read by humans as well as by machines.

archive  data format  integration	The role of the DTD in the document base

DTD, Document Type Definition

The document base can be setup with all the flexibility and benefits provided by SGML. But it is obvious, that the design of the DTDs determines the usability of the document base. In principle, as I see it, there are three classes of DTDs

Layout oriented

rendition

The focus of this DTD style is rendition, therefore the capabilities are mostly oriented to publishing tools. This kind of DTD cannot be used for data exchange between tools. This DTD style is not even appropriate to build the document base.

Presentation oriented

DOCBOOK.DTD  MSRREP.DTD   presentation   structure

The focus of this DTD style is the structure of the presentation layer but not rendering. So such DTDs allow to support various layouts on many different media. An example for this class of DTDs is DOCBOOK.DTD or MSRREP.DTD ( ). This sort of DTD is well suited for the document base if the required presentations reflect layout and global rearrangement. It is not really possible to extract information based on the content of the document, since the semantic of the DTD is oriented on the structure of a presentation rather than on the a data model of the presented subjects.

Database oriented

data model  data scheme  database

This class of DTDs is essential if data exchange is performed via the document base. The focus of such DTDs is a data model reflecting the reality of the objects in the process. This means, that the semantic of the DTDs reflect the details of the presented subjects. For example we have <part> instead of <chapter> or <interface-prms> instead of <table> .

relational data model

<company>
  <emps>
    <emp emp-no="4321"
         name="Bernhard Weichel"
         adress="stuttgart"/>
    <emp emp-no="12345"
         name="Helmut Gengenbach"
         adress="schwieberdingen"/>
  </emps>
  <depts>
    <dept name="K3/EES4" mgr="4321"/>
    <dept name="FV/PLI"  mgr="0815"/>
  </dept>
</company>

HyTime   ID/IDREF   MSRSW.DTD  OOP  XLL   inheritance   namespace   subclassing

As one example for an object oriented model is given in the following figure ( ). It comes from MSRSW.DTD which is used in the development of software for an engine control system. The DTD is the data scheme for calibration parameters in theECU . Such a parameter can be a single value, a curve or even a map. This is reflected in the DTD by some alternative branches used to support alternative details. For example, a single value only has a value axis but no x or y axis. A curve has a value axis, an x axis but no y axis. The map however has three axis (value, x and y). <sw-param-class> denotes the class of the parameter and determines which alternatives must be used. This illustrates, how subclassing can be performed using object oriented DTDs .

Example of an object oriented DTD

Instance for calibration parameter

<sw-param>
   <long-name>Lambda Wirkungsgrad</long-name>
   <short-name>etalam</short-name>
   <sw-param-class>curve_individual</sw-param-class>
   <desc>
     Abbildung Basis-Lambda
     auf den Lambda-Wirkungsgrad ohne Eingriff
     bezogen auf optimales Moment bei Lambda=1
   </desc>
   <sw-param-array-x>
      <sw-param-axis-x>
         <sw-axis-individual>
            <sw-variable-ref>lambas</sw-variable-ref>
            <max-count>10</max-count>
         </sw-axis-individual>
      </sw-param-axis-x>
      <sw-param-axis-values>
         <sw-compu-method-ref>rel_ub_b127b5</sw-compu-method-ref>
      </sw-param-axis-values>
   <sw-addressing-method-ref>NearRomByte</sw-addressing-method-ref>
   <sw-param-record-layout-ref>KlAUbSstUbWUb</sw-param-record-layout-ref>
   <sw-code-syntax-ref>KlNearAUbSstUbUb</sw-code-syntax-ref>
</sw-param>

engineering process  life cycle prcess phase

If the DTDs are bound to support all the phases of an engineering process ( ), a new set of problems must be solved:

HyTime    ID/IDREF   MSRSW.DTD   SGML/XML editor   XLL   data model   occurence  schema

In the first place it appears to make sense to have a sub-DTD for each process phase or even one per tool. This would allow to define the data set per process phase by this DTD. On the other hand, this approach requires specific SGML applications for each process phase. The knowledge about the data structures would also be process phase specific.

One DTD for different process phases

transformation

When dealing with database oriented SGML/XML instances all known methods of transformation respectively retrieval apply.

DOM, Document Object Model   migration	Query language

query language

When using a database oriented DTD, a powerful query language is essential to leverage all the power of this. Especially the following features are required.

Finding invalid parameters

descendant   // consider all descendants
[   // for which is true:
@f-id-class=="PRM" &   // Attribute f-id-class is "PRM" AND
child   // has a child
[   // for which is true:
?prm-char &   // GID is "PRM-CHAR" and
child[?min].data   // child with GID "MIN"
>   // is greater than one of
// the children with GID "TYP" or "MAX"
child[?typ | ?max].data  ]  ]  .   // for each of those
child[?short-name]   // use children with GID "SHORT-NAME"
. data   // for each of those return PCDATA

MSRSW.DTD  union

The next example ( ) shows how multiple instances are queried while data is retrieved from multiple places in each instance. The query is based on the MSRSW.DTD (see ) The result of the query is all contents of all data dictionaries, in other words the united data dictionary.

Merging Data

source("sim.sgm", "impl.sgm")   // two sources "sim.sgm" as well as "impl.sgm"
.(   // for each of those
root,   // use root
// as well as path to ...
path("sw-function-spec/sw-function/sw-function-variants/sw-function-variant")  )  .   // for each of those
// path down to sw-data-dictionary
path("sw-data-dictionary-spec/sw-datadictionaries/sw-data-dictionary")  .contents   // for each of those return the contents

MSR-Instance for parameter set

  <PRMS>    <PRM>      <LONG-NAME>Long-name</LONG-NAME>      <SHORT-NAME>sn</SHORT-NAME>      <DESC>Das ist die Beschreibung des Parameters sn</DESC>      <PRM-CHAR>        <COND><P>Bedingung 1</P></COND>        <MIN>min-1</MIN>        <TYP>typ-1</TYP>        <MAX>max-1</MAX>        <REMARK><P>Das ist der Hinweis zur Bedingung 1</P></REMARK>      </PRM-CHAR>      <PRM-CHAR>        <COND><P>Bedingung 2</P></COND>        <MIN>min 2</MIN>        <TYP>typ-2</TYP>        <MAX>max-2</MAX>        <UNIT>unit</UNIT>      </PRM-CHAR>    </PRM>      <PRM>      <LONG-NAME>Abs-tol-Parameter</LONG-NAME>      <SHORT-NAME>atsn</SHORT-NAME>      <DESC>Das ist ein abs-tol-parameter</DESC>      <PRM-CHAR>        <ABS>abs</ABS>        <TOL>tol</TOL>        <UNIT>unit</UNIT>        <REMARK><P>Das ist die Anmerkung zu abstol</P></REMARK>      </PRM-CHAR>    </PRM>      <PRM>      <LONG-NAME>Textparameter</LONG-NAME>      <SHORT-NAME>txt</SHORT-NAME>      <PRM-CHAR>        <TEXT>Das ist der text des Parameters</TEXT>      </PRM-CHAR>    </PRM>  </PRMS>

Query to retrieve a parameter set as a table

<|st.table|>(*hook:=this)   // create the table
// keep hook in variable
{  <|st.title|>node{*hook._GID | *hook.GID},   // make Title
<|st.cols|>node   // define columns
{  <|st.col, @width:="4cm"|>node,  <|st.col, @width:="2cm"|>node,  <|st.col, @width:="1.5cm"|>node,  <|st.col, @width:="1.5cm"|>node,  <|st.col, @width:="1.5cm"|>node,  <|st.col, @width:="1.5cm"|>node,  <|st.col, @width:="1.5cm"|>node,  <|st.col, @width:="2cm"|>node,  <|st.col, @width:="1.5cm"|>node  },  <|st.thead|>node   // Table head
{  <|st.row|>node  {  <|st.entry|>node{"Bezeichnung"},  <|st.entry|>node{"Kürzel"},  <|st.entry|>node{"Min."},  <|st.entry|>node{"Typ."},  <|st.entry|>node{"Max."},  <|st.entry|>node{"Abs."},  <|st.entry|>node{"Tol."},  <|st.entry|>node{"Einheit"},  <|st.entry|>node{"Hinw."}  }  },   <|st.tbody|>*hook   // Table body, hooked to parameter-table
{  <|st.row|>child  .child[?prm-char]   // a table row for each <prm-char>
{(*curent:=this).null   // save actual prm-char in variable
<|st.entry,   // an entry for title
@hjust:="l"|>node  {  (*current.parent  .child[?long-name]  .contents   // use cousin <long-name>
|   // or
*current.parent.gid),   // or GID of table element
<|q.pb|>that.child[?cond]  .contents   // add <cond>
{" - ",contents}  },   <|st.entry|>node  {*current.left[?short-name]  .contents},   // an entry for <short-name>
(<|st.entry,   // spanned entry for <text>
@w:="9cm",@hjust:="l",  @hspan:=6|>child[?text]{contents} |     // or individual entries for
(<|st.entry|>node{that.child[?min].contents},   // <min>
<|st.entry|>node{that.child[?typ].contents},   // <typ>
<|st.entry|>node{that.child[?max].contents},   // <max>
<|st.entry|>node{that.child[?abs].contents},   // <abs>
<|st.entry|>node{that.child[?tol].contents},   // <tol>
<|st.entry|>node{that.child[?unit].contents}   // <unit>
)  ),   <|st.entry|>node   // entry for remark
{  that.child[?remark]  .(count(parent.parent   // number counter for remark
.left.child[?prm-char]   // count grand cousins
.child[?remark]   //
,  parent  .left[?prm-char]   // and cousins
.child[?remark]  )+1||"."  )  |null   // leave cell blank if
// there is no remark
}  }  }  }

SGML/XML editor   authoring

Obviously it is highly recommended that instances for database oriented DTDs are generated automatically by tools rather than edited manually. But in some circumstances it is required to do manual authoring (e.g. if no generator is available, for debug purposes etc.). If some basic funtionality is available in the SGML editor, direct authoring becomes practicable (but still not ideal).

link  link manager

As discussed above ( ) in a database oriented DTD there are links with well defined semantics. There are many different semantics so there are many different link types. For example if a function is importing a variable, the related link should not end at a company or at a measurement unit. For manual authoring, there must be means to follow these different link types. An example of a link manager for the MSRSW.DTD is shown in in the figure below ( ). In the left pane of this dialog, all link types are displayed. The available objects belonging to the selected link type (in this case variable) are shown in the right pane.

Link manager

template

Database oriented DTDs tend to be very complex. There are a lot of elements with well defined semantics. On the other hand there are object classes as shown in . To support capturing such complex strictures, a template strategy can be used with the following features.

Inserting and defining templates

data model  data type  file size   schema   semantics	The document base in the MSR consortium

MSR  automotive

In the German automotive industry, there is a consortium of car manufacturers and automotive equipment suppliers made up of the companies BMW AG, Daimler Benz AG, Porsche AG, Volkswagen AG, Robert Bosch GmbH, Hella KG Hueck & Co. and Siemens AG.

MSRSYS.DTD

MSRSYS.DTD

This database oriented DTD is used to describe an to specify entire control systems with all its mechanical and electrical components. This DTD provides detailed structures for project data, architectures, signals, connections, electrical, properties, mechanical properties. This DTD was successfully used in multiple projects within a big automotive manufacturer and his suppliers.

MSRNET.DTD

CAN MSRNET.DTD

This highly database oriented DTD is used to transport information about networks in the vehicle. It allows to specify the information transported on the network, how this information is packed into messages, the network topology etc. This DTD is implemented as import/export facility in the CAN tools from Vector Informatik (http://www.vector-informatik.de ). This DTD is actually used by another automotive manufacturer to support databases for the next generation of automotive networks.

MSRSW.DTD

ASCET  MSRSW.DTD

This highly database oriented DTD is used to specify the software forECU s. The examples in this presentation were taken from applications with MSRSW.DTD. This DTD is successfully used in projects across companies as well as across different business units in one company while each partner uses different engineering tools and SGML/XML tools. This DTD is supported in the system design tools ASCET (http://www.etas.de )

In one case a single document of thousands of pages as well as on-line documentation is generated using MSRSW.DTD. Parts are contributed by the customer as well as Bosch engineers and merged on SGML/XML level. In the same project, data definitions are transferred in the same instance and introduced in the software build process.

MSRFMEA.DTD

FMEA MSRFMEA.DTD

This DTD is no yet published since it is in a very experimental status. Its design is totally database oriented. The data model behind it was directly derived from the data model of an existing tool for FMEA  (Failure mode and effect analysis) . This data model was generalized to eliminate the tool specifics.

MSRREP.DTD

MSRREP.DTD

This presentation oriented DTD is used to write reports and specifications not yet covered by the other DTDs. All the MSR documentation is done using MSRREP.DTD.

subclassing	Natural addressing in MSR

linking

As already mentioned (e.g. ), MSR has a specific method of adressing linked resources which exists in parallel to the methods provided by SGML/XML. This method is based on the following principles:

Natural adressing in MSR

<companies>  <company>    <short-name>bosch</short-name>
...  <team-members>  <team-member>    <short-name>wl</short-name>
<long-name>Bernhard Weichel</long-name>  ...   <company>  <short-name>foo</short-name>   ...  <team-members>  <team-member>    <short-name>wl</short-name>
<long-name>Gerhard Walter</long-name> </companies>   <modifications>  <modifcation>    <team-member-ref>bosch/wl</team-member-ref>

context  link    namespace   schema	Conclusion