MSR-MEDOC REPORT SYSTEM SGML NETWORK DIAGNOSIS FMEA SOFTWARE ACTIVITIES ACTIVITIES PARTNER INSIDER REPORTS HOME RESOURCES NEWS
 

 

 

Report

When MSR started to use SGML/XML for documenting the MSR activities itself, it became clear that a DTD for arbitrary documents is required. So MSRREP.DTD was developed and can be used to write reports and specifications not yet covered by the other DTDs (e.g. test reports etc.)

MSRREP.DTD provides:

  • Generic document structure (chapters, paragraphs etc.)
  • Detailed model for change management


back to top

 

 

Software

For specifying and documenting software for electronic control units the MSRSW.DTD is used. 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 increasingly supported by system design tools (e.g. ASCET/SD http://www.etas.de).

The DTD covers:

  • Data dictionary
  • Functional specifications
  • Calibration parameters

In one project a single document of about 1400 of pages as well as on-line documentation was generated using MSRSW.DTD. Parts were contributed by the different project partners using different tools. The data was integrated on SGML/XML level and used not only for document preparation but also for linking engineering tools (e.g. transferring data definitions).
Software for ECU’s.

back to top

 

 

FMEA

In the area of Failure Mode and Effect analysis, an experimental DTD (MSRFMEA.DTD) was developed. DTD is not 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. This data model was generalized to eliminate the tool specifics.
The MSRFMEA.DTD will be used in several pilot projects. After these projects it will be finalized.

back to top

 

 

Diagnosis

The latest activity is the documentation for diagnosis (on board as well as off board). The work started in spring 98. This domain touches all the other DTDs. So we expect all the information being available in instances of MSRSYS, MSRNET, MSRSW, MSRFMEA. Nevertheless an integrated document set for diagnosis is required.
For configuration of off board test systems, an SGML DTD is defined by ASAP. This DTD is compatible with the strategies of MSR.

back to top

 

 

Network

For specification and documentation of on board networks, the MSRNET.DTD is used. It allows to specify
the information transported on the network, packed these signals into messages the network topology etc.
This DTD is implemented as import/export facility in the CAN tools from CAN Vector Informatics (http://www.vector-informatik.de). It is actually used by a big automotive manufacturer to support their databases for the next generation of automotive networks.

back to top

 

 

SGML/XML application profile of MSR

The datamodels defined for MEDOC are implemented as SGML/XML DTDs. All these MSR DTDs while implementing specific data models for their domain have the same basic principles:

  • Same link model for all DTDs (supporting ID/IDREF, HyTime, and MSR semantic addressing simultaneously). This model allows instances of the various MSR DTDs to be linked together and used as an entire database. The link classes are unique across the entire MSR DTD system.
  • basic models (generic text sections, parameters, architectures, etc.)
  • configuration capabilities
  • subclassing methods using < ...class> elements.
  • administrative data applicable to implement version control even for subtrees in one instance. This is useful if an instance is built of fragments delivered by different project partners.
  • Same generic approaches for constructing the DTDs (e.g. naming conventions, architectures)

    back to top

 

 

System

MSR started in the domain of entire systems. The result is the MSRSYS.DTD.which is used to describe and to specify entire control systems with all its mechanical and electrical components. This DTD provides detailed structures for:

  • project data
  • parts and system decomposition
  • architectures with signal, interfaces, ports and connection specification
  • connections
  • electrical characteristics
  • mechanical characteristics
  • optical and acoustical characteristics
  • environmental characteristics

This DTD was successfully used in multiple projects within a big automotive manufacturer and his suppliers.

back to top


HELP GLOSSARY DOWNLOADS MEMBERS CONTACT HELP