Allgemeine Elemente

Attribute Semantische

Allgemeine Elemente

Before we go through now the container elements of the ODX basic structure in detail, we first take a look at the common elements that need to be optional or mandatory ODX present in all elements. This begins with the ADMIN-DATA, the information about the version control and configuration management and include the COMPANY-DATA, company information, for example, have the people, who compiled the data contained can. ODX each object can be assigned and usually has a SHORT-NAME. The SHORT-NAME is a type variable name with which an object can be identified by a human user. The same effect can be achieved with a LONG-NAME. The difference between SHORT and LONG-NAME-NAME is the maximum length and type of characters that may be contained in the name. Optional you can enter for most objects in a section DESCRIPTIONS a descriptive comment. For the machining of ODX data, the IDs are provided. IDs come in two forms. First, as the ID, which should be unique within the entire database. This ratio is normally set automatically by the authoring tool. As an alternative to ID, which can change during the life of the ODX database also is the OID. The OID is an indicator, which will remain throughout the life here clearly and without change.

Common elements for all objects I ODX

In addition, ASAM ODX has provided for that vendor-specific extensions can be installed. The vendor-specific extensions should be integrated as so-called SPECIAL-DATA-GROUPS in ODX. And finally there is the possibility of parts of the ODX data be marked so that they are only for certain user groups and intended to be accessible. This can be done on the section and ADDITIONAL-AUDIENCE AUDIENCES.

Common elements for all objects ODX-II

The following are the common items are listed once again:

• ADMIN-DATA

  Information about the version control and configuration management

• COM­PA­NY-DATA

  Company information (eg functions, members of the team and company-specific data)

• SHORT-NAME

  Short name of an ODX-object (max. 128 characters), is used by ODX Tools for the reference concept of the name,

• LONG-NAME

  Long name of the ODX object for display within the GUI (max. 255 characters), ie for the ODX-user

• DESC

  Descriptive text for the ODX-object (no length limit, with HTML format tags) for the documentation

• ID

  Over the entire database unique identifier (or abbreviation code) for a ODX object is used for the reference concept of ODX Identifier

• OID

  Over the entire life cycle of clear identification, similar to the Universally Unique Identifier (UUID) to ISO / IEC 11578:1996

• SDGS – Spe­cial Data Groups

  • Standard Erweiterungsmechanismus
  • All non-standard data structures are stored
  • Only the structure and the contents are not defined
  • Tree structure with no restrictions (any depth, recursion, etc.)
  • Very complex data structures mapped
  • A diagnostic tool can ignore SDGs
  • Example: COMPANYDOC-INFO

• AUDIENCE & ADDITIONAL-AUDIENCES

  • Assignment of the availability of diagnostic elements to specific user groups
  • 5 pre-defined Boolean data
  • Can be expanded to include custom attributes (ADDITIONAL-AUDIENCES)

Attribute Semantische

With the help of semantic attributes can be classified into ODX following objects:

• Diagnostic Services
• Logical Links
• Parameter
• Jobs
• Sessions
• Values
• Configurations
• etc.

This allows the diagnostic run-time system, the corresponding object is not selected on the basis of the name but on the basis of these classifications. Thus, generic, test sequences are generated and executed, which operate regardless of the parameterization. For example, the diagnostic service can be used to read the error memory group-wide or industry-wide standard to "DEFAULT FAULTREAD" set. A diagnostic tester must now do not know the exact, firm-specific name of the service, but calls it on its semantic attribute.

The objects, one or more semantic attributes are added. The following values ​​are predefined in the Standard:

• COMMUNICATION

  To show that this (is used in connection with DIAGNOSTIC CLASS = "Red Hat" and DIAGNOSTIC CLASS = "STOPCOM") related to the communication

• SESSION

  Switching to another diagnostic session

• SECURITY

  Allows a security-access

• IDENTIFICATION

  Reading the ECU or Flash ID

• FAULTREAD

  Read the error memory entries

• FAULTCLEAR

  Clearing the fault memory

• DEFAULT FAULT CLEAR

  Erase the fault memory entries (Should be unique)

• ENVREAD

  Reading the environment data of a fault memory entry

• VARCODING

  Job or diagnostic service for the model coding

• STOREDDATA

  Read and write data stored

• CURRENT DATA

  Read recent data

• MEMORY

  Read and write the ECU memory

• CONTROL

  Starting and stopping routines or access to the results of the routines

• CALIBRATION

  Job or diagnostic service for the ECU calibration

• ROUTINE

  Starting and stopping routines or access to the results of the routines

• FUNCTION

  Execution of functions

• ECUDOWNLOAD

  Job or diagnostic service for the opening of a download to the ECU (transfer data)

• UPLOAD

  Job or diagnostic service for the opening of an upload from the ECU (transfer data)

• FLASH JOB

  Job for reprogramming of the ECU memory

• TESTER PRESENT

  Features a Tester Present for maintaining the current diagnostic session (should be unique)

• DEFINE-DYN-MESSAGE

  Service, which features a record-DYN id

• READ-DYN-DEF-MESSAGE

  Service, the data on a DYN-ID reads

• MEMORY READ
  

  Job or diagnostic service to the reading the ECU memory, such as ReadMemoryByAddress

• MEMORY WRITE

  Job or diagnostic service for writing the control device memory, such as WriteMemoryByAddress

• STOREDDATAREAD

  Job or diagnostic service for reading data, such as ReadDataByIdentifier

• STOREDDATAWRITE

  Job or diagnostic service to the writing of data, such as WriteDataByIdentifier

• CODING VARIANT READ

  Job or diagnostic service for reading data to model coding

• CODING VARIANT WRITE

  Job or diagnostic service for writing data to the model coding

• EVENT READ

  Job or diagnostic service for reading of event-driven responses from the control unit

• EVENT CLEAR

  Reset the event controller in the controller to stop sending event-driven responses

• DEFAULT EVENT READ

  Standard job or diagnostic service for reading of event-driven responses from the controller (should be unique)

• DEFAULT EVENT CLEAR

  Standard reset the event controller in the controller to stop sending event-driven responses (Should be unique)

• ID

  Identifier

• SERVICE-ID

  Service Identifier

• Subfunction

  Subfunction of a service identifier

• CONTROL

  Control Parameters

• DATA

  Data

• LOCAL ID
  

  Local Identifier

• COMMON ID

  Common identifier

• CONTROL PARAMETER ID

  Control Parameter Identifier

• DATA-ID

  Data Identifier

• DATA PACKAGE-ID

  Data Package Identifier

• PARAMETER ID

  Parameter Identifier

• DYN id

  Request a response within one or dynamically defined identifier