Presentation of Results

MSR Working Group MEDOC

Presentation of Results
Final Report
[msr-tr-medoc]
Revision: 3
This document reports the activities and results of MSR-MEDOC working group. The documentation comprises of three parts:
  • Management overview
  • Technical overview
  • Working documents which are mainly given as references.


I. Document management

Presentation of Results
I. Document management

team members
Name | Company
Bernhard Weichel, Robert Bosch GmbH | MSR-MEDOC
Ulrich Vogel, BMW Group | MSR-MEDOC
Herbert Klein, XI-Works | MSR-MEDOC
version overview
Version | Date | Publisher | State
 | 2002-07-01 | Herbert Klein, XI-Works |
 | 2002-07-01 | Herbert Klein, XI-Works |
1 | 2001-10-24 |  | WD
modifications
Change | Related to
DTD Descriptions, documentation strategy Reason: - | Content
New Chapters "Target Domains and Document Type Definitions" and "Available Documents". Reason: Contents are missing | Content
Content
modifications included
Date | Chapter | Change | Related to
2002-07-01 | Gesamt | DTD Descriptions, documentation strategy Reason: - | Content
2002-07-01 | Gesamt | New Chapters "Target Domains and Document Type Definitions" and "Available Documents". Reason: Contents are missing | Content
 |  | Definition of Indexes, technical terms. Migration to MSRREP V210 XML. Reason: Document was written in MSRREP V0.16.6. | Content


1. Management overview

Presentation of Results
1. Management overview

What is MSR?
The MSR consortium (Manufacturer Supplier Relationship) is an initiative of the top managers of development (E-Leiter) of the German car makers. It is run as task 11 within strategy circle 4 (electric/electronical development).
The mission is the development of cost reduction potentials by cooperation in non competitive areas and the use of synergy potentials in a common projects.
MSR supports the joint development of car manufacturers and their electric/electronic component and system suppliers by enabling process synchronization and proper information exchange.
What is MSR/MEDOC?
MSR/MEDOC is a subtask of the MSR consortium. MEDOC is an acronym for MSR Engineering Data Objects and Contents.
MEDOC develops methods standards and implementation for information exchange in the engineering process.
The vision
MSR/MEDOC enables everybody - regardless of their tools and data management environment - to exchange information and work products online. Team members can retrieve, process and add information at any time and any location. MSR/MEDOC provides enabling technologies by applying internet standards such as XML in the distributed engineering process.
Objectives
The main objectives of MSR/MEDOC are:
  • Seamless, continuous and consistently structured product documentation for electric/electronic components and systems across the entire life cycle e.g. for requirement specification
  • Support of views appearing within the development cycle
  • integration of heterogeneous IT environments Product Data Management / Technical Data Management
Strategy
In order to achieve the intended objectives, MSR/MEDOC used the following approach:
  • Analysis of the entire E/E-system and identification of technical and application domains on the level of components and systems
  • Building information models for the identified domains and applying appropriate implementation technology
  • Verification of the results within selected car component series development projects
Results
Results of MSR/MEDOC are the defined structures, modelled as XML-DTDs (eXtensible Markup Language - Document Type Definitions):
Developed Structure | Covered Domain
MSRSYS | Electrical hardware systems and components
MSRSW | Software for electronic control systems
MSRREP | General documentation and change management
MSRFMEA | Failure Mode and Effect analysis
MSRDIA | Diagnostic documentation and specification
MSRNET | Network systems
MSRDCI | Document Control Instance contains rules for formal content check XML-instances
MSRCC | Container catalog for exchanging Datasets - and files for code, configuration metadata and documentation
The developed structures are supported by additional products:
  • Sample Implementation
  • Documentation comprising of overview, structural principles, reference material user guide
  • Auxillary structures to support particular implementations (MSRDCI)


2. Technical overview

Presentation of Results
2. Technical overview

Contents of this chapter:
  • 2.1. The XML paradigm
  • 2.2. Objectives
  • 2.3. Strategy
  • 2.4. Target domains and Document Type Definitions


2.1. The XML paradigm

Derived from the global MSR/MEDOC vision
  • "MSR/MEDOC enables everybody - regardless of their tools and data management environment - to exchange information and work products online. Team members can retrieve, process and add information at any time and any location. MSR/MEDOC provides enabling technologies by applying internet standards such as XML in the distributed engineering process"
MSR/MEDOC applies the potential of XML as enabling technologies to the domain of embedded electronic systems (in particular the automotive). This results in vertical standards which are prerequisite for applying e-business approaches in the engineering process.
The gap between engineering data, database contents and document presentations can be overcome by establishing the XML based middle layer as shown in Document layer architecture
Document layer architecture
Figure 1: Document layer architecture


2.2. Objectives

The general objectives are refined as:
  • Exchange of information between car manufacturer and supplier without data conversion
  • Identification of relevant Information units and their significance in their particular context.
  • Comprehensive data architecture (e.g. cross document linking)
  • Implementation platform and tool independent - thus providing long term data (re-)usability


2.3. Strategy

MSR/MEDOC used the strategy
  • Analysis of the entire E/E-system and identification of technical and application domains on the level of components and systems
  • Building information models for the identified domains and applying appropriate implementation technology
  • Using SGML/XML to implement the data models
  • Identification the commonalities within the various domains and deriving a common technology (XML application profile, documented in MSR-TR-CAP)
  • Initiation and application of a process for information modelling within the application profile
  • Verification of the results within selected car component series development projects
  • Improvement of the developed structure according to the feedback of the verification.
  • Control the process by a steering committee
Figure 2: MEDOC Organization


2.4. Target domains and Document Type Definitions


2.4.1. MSRSYS

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.


2.4.2. MSRSW

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. .
The DTD covers:
  • Data dictionary
  • Functional specifications
  • Calibration parameters
In one project a single document of about 3000 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 of Software for ECU's).


2.4.2.1. MSRREP

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
In the meanwhile this DTD is used for many use cases with additional processing functionality, which can be attached on every element with special attributes.


2.4.2.2. MSRFMEA

For documentation in the area of Failure Mode and Effects analysis, the MSRFMEA.DTD was developed.
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 has been used in several projects. An implementation in the IQ-FMEA Tool is available.


2.4.2.3. MSRDIA

For documentation of diagnosis specifications (on board as well as off board). 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 ASAM. This DTD is compatible with the all strategies of MSR.


2.4.3. MSRNET

For specification and documentation of on board networks, the MSRNET.DTD (MSR Network DTD) is used. It allows to specify the information transported on the network, packed these signals into messages the network topology etc.


2.4.4. MSRDCI

For definition of a set of rules which can be used by an dci-checker to validate the contents of an xml instance (e.g. an MSRSW instance). This may be used to check instances of one DTD with different contents in a different manner. E.g. an MSRSW instance with PACO content or an MSRSW instance with software functions(FDEFs) are based on the same DTD but have different contents. So they can be checked by different DCI rule sets which are located in different DCI instances.


2.4.5. MSRCC

In case of joint engineering efforts it is necessary to synchronize the engineering data bases. The MSRCC (MSR Container Catalog) is an document which describes the metadata of exchange data objects which are located in an exchange container (e.g. a ZIP file). It is a generic approach for exchange of engineering data and its configuration.
The container comprises of engineering objects such as source codes, documentation, compiled objects etc. and meta information about the exchanged object such as creator, name, version info and configuration.


3. Documentation

Presentation of Results
3. Documentation

The documentation for all target domains and DTDs of MSR-MEDOC can be found at MSR MEDOC Website for download or in the MSR MEDOC documentation set


3.1. General Documentation strategy

The name of a document starts with the following parts separated by "-":
domain | This is the domain where the document belongs to. In most of the cases it is the name of the DTD. Otherwise the domain is "MSR".
document class | The document class as defined in 3.1.1. Classes of documents
topic | This optional part shows the topic within the domain. E.g. in "msrsw-tr-paco", "paco" is the topic (as a shortcut for "document overview")
language | The optional language of the document. ISO 639, 2-character code e.g. "en"(english) or de(german)
state | The optional release state of the document as defined in 3.1.2. State of documents
date | The optional release date of the document.
distribution kit | The optional format of the document as defined in 3.1.3. Distribution of Documents, e.g. pdf, html
Examples are:
MSRSYS-TR-FHT: <MSRSYS DTD, Technical Report, Formatter for HTML>
MSR-TR-XML: <MSR, Technical Report, XML strategy>


3.1.1. Classes of documents

For each DTD the following documents should exist:
(TR) Technical report
Technical reports reflect statements and studies to various topics. These can be DTD related as well as generic.
(SP) Structural principles
This is the document which is maintained during the development of the DTD. It reflects the actual results of data modeling, semantics and application hints, and SGML elements. The level of detail and maturity increases during the process of DTD development. This document is most likely available when the DTD is released.
As this document is accompanying the development process, its final version is neither an ideal user guide nor an ideal reference manual. Nevertheless it is useful for implementors as well as for users.
(PG) Processing guide
This document is mostly the specification for formatting (paper as well as online) engines.
This document is written when the DTD is finished. It may receive some information available already the structural principles. Its scope is to specify the processing of instances.
(EA) Elements and attributes
This document is the reference description for elements and attributes. It contains all elements and attributes of the specific DTD.
This document is used by implementors as well as by users.
(UG) User guide
This document is (authoring environment independent) description how to generate a new document. Its information is already there in the other documents. The user guide is presented in a tutorial style.
(SI) Sample instance
This instance is intended as a sample to illustrate the general usage of the DTD. It is simple enough to illustrate how the DTD works.
(RI) Reference instance
This instance is intended to be used as a test case for implementations. It should use all elements and cases. Furthermore it should give an impression how real project instances should look like (size, amount of element etc.).
It is possible to have multiple reference instances:
(RIP) performance | useful for performance tests
(RIV) volume | useful for resource tests
(RIC) content | as an example for a complex instance to show all the features of a DTD
(RIA1) alternatives | in some cases, there are alternative content models which prohibit full path coverage. In this case it is necessary to provide an instance for each alternative.
In addition to the DTD related documents there are technical reports (TR) resp. technical notes (TN)


3.1.2. State of documents

The documents receive one of the following states:
PD | Planned document
WD | Working Draft This document is subject to be changed without notice. It is the actual version when work is in progress within a working group.
CD | Comitee Draft This document is finalized by the Working group and is in the reviewing process.
RD | Released document This document is released and official.


3.1.3. Distribution of Documents

The released documents are placed on the MSR server (http://www.msr-wg.de/medoc). The filename reflect document scope, document class, version and content. The document are published as the following sets:
dtd | The DTD distribution without documentation
pdf | Document in PDF format
html | Document in HTML format
help | Document in MS HTML-Help format
ps | Document in PostScript format
source | Document in source format(most likely XML) including all graphics
ppt | The document in MS Power Point format
doc | The document in MS Word format
xls | Document in MS Excel format
HTML and Source sets are delivered as ZIP files. The filename of the set is built as a string with
<domain, document-class,[topic], [language], state, date (as yyyymmdd), distribution-kit>.zip Examples are:
msrsw-sp-en-cd-19980710-html.zip
msrsw-sp-de-rd-19980710-source.zip
msrsw-tr-paco-en-rd-20020703-source.zip


4. Literature

Presentation of Results
4. Literature

Additional information can be found at MSR MEDOC Website for download or in the MSR MEDOC docmentation set . Especially the following presentations are an good introduction in MEDOC target domains.
  • [Presentation BadenBaden 98;]
  • [Presentation SGML/Europe 95;]
  • [Presentation SGML/Europe 98;]
  • [Presentation XML/Europe 2001;]
  • [Presentation MSRFMEA at IQ/User-Group Meeting 1999;]


5. Glossary

Presentation of Results
5. Glossary

DTD
Document Type Definition
XML
eXtensible Markup Language
ASAM
Association for Standardization of Automation- and Measuring Systems
Instance
An XML document is also called an instance, because it based on the structures of a DTD.


Technical Terms

Presentation of Results
Technical Terms


!!MISSING FIXTEXT: name= language=EN

E-Leiter | 1.
MSR consortium | 1.
MSR-MEDOC |
MSR/MEDOC | 1.


Organisations

MSR/MEDOC


Products

MSR/MEDOC | 1. 2.1.
MSRCC | 1.
MSRDCI | 1.
MSRDIA | 1.
MSRFMEA | 1.
MSRNET | 1.
MSRREP | 1.
MSRSW | 1.
MSRSYS | 1.
SGML | 2.3.
XML |