The glossary contains central terms. The explanations make reference in come cases to terminology used used within the scope of MSRSYS.DTD.
add-info, add-spec
Elements within the MSRSYS.DTD that, as well as given topics/titles, enable a freely structured documentation of additional specifications (add-spec) and additional information (add-info) for objects as well as the prescribed description structure (add-info).
ASAP
The ASAP interfaces have been agreed by the "Study Group for Standardization of Application Systems (ASAP)". Members of this study group are the German Automobile Manufacturers and companies from the supplier industry.
Data
Contents of software parameters (parameter contents)
Data status
Defined contents of the Software-Parameter (parameter contents) at a certain point in time. The data status is identified by a version number.
Decomposition
Breakdown of a software function into sub-functions.
Function
Function is understood as being a certain requirement or property of the overall system that can be realized either by hardware, software or a combination of both.
Function analysis
The function analysis contains the description of the contexts, the functions (hierarchical, including diagnostic functions, safety functions etc.) and the information flows (informal). A formal definition, an informal description, as well as application notes and customer-servicing notes are documented for each function.
Hardware function
Function within the behavior that has been realized in the hardware.
Hardware module
Constituent of a hardware component (Part-Type); in certain circumstances the component itself.
Integration
Phase in which the individual modules are joined. The integration can be carried out in the testing and/or target environment.
Logical function
A function within the behavioral description.
MSRDOCDTD
Exchange structure defined within the scope of the project in the standard SGML (ISO 8879).
OSEK
OSEK stands for: "Open Systems and the Corresponding Interfaces for Automotive Electronics". OSEK was established in May 1993 by companies in the German automobile industry. Founding partners were: BMW, Bosch, Daimler-Benz, Opel, Siemens and VW. Project coordinator is the IIT at the University of Karlsruhe (Institue of Industrial Information Sytems). Peugeot and Renault joined the project with the French project VDX-approach (Vehicle Distribute eXecutive). The German and the French projects were merged into OSEK/VDX. The topics of operating systems, communication and net work management are covered in OSEK/VDX. Refer to Proceedings of the 1st International Workshop on Open Systems in Automotive Networks
Part-type, part
Central elements within the MSRDOCDTD for the description of the hardware-component structure.
Processing
The processing describes (in the document "Processing Guide for the MSRDOCDTD") the processing and layout definitions for the MSRDOCDTD. I.e. a description is given of how an SGML entity of this DTD is converted by a formatter into a technical layout for printing a document.
Program
Part of the Softwaresoftware in the control unit that is capable of running. Data are handled separately, i.e. not as part of the program as these are developed in a separate process (compare 1.2.8. Application (calibration)).
Programmability
Characteristic of a component (e.g. a control unit) that describes the form in whhich and the extent to which the component can be programmed (end-of-line, off-line and field programmability).
Program status
Executable code in the control unit without data (parameters etc.)
View
The MSRSYS.DTD can take data in two views (views): "requirements" and "product-spec".
Software
Software capable of running, i.e. program and data in one control unit.
Software function
A function realized in the software Functionin a control unit.
Software module
A unit that can be combined by a compiler that can also comprise several software functions.
Software status
Combination of Program statusprogram status and Data statusdata status
System analysis
In the system analysis, the system is described at a logic level. The logical function model thereby given can be simulated.
System design
The physical function model is derived form the logical function model in the system design.