 | 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
-
- 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.
|