ASAM MCD-2D ODX V2.0标准：汽车ECU诊断与编程数据交换规范

需积分: 1 74 浏览量更新于2024-06-28 收藏 3.1MB PDF 举报

ASAM-MCD-2D(ODX)-V2.0.0-ReleaseSpecification 是一个由 ASAM（Automotive Standardization and Application Platform Management e.V.）制定的规范，它专注于定义在汽车行业电子控制单元（ECU）的诊断和编程数据在系统供应商、汽车制造商和售后服务中心之间的传输需求。这个标准旨在解决当前汽车行业普遍存在的问题，即依赖纸质文档来记录车辆ECU的诊断数据流信息，这在开发工具设置和售后服务诊断设备配置方面造成了效率低下和信息共享的困难。 ODX（On-Board Diagnostic）诊断数据库是ASAM-MCD-2D的核心部分，它提供了一个标准化的方式来存储和交换车辆ECU的数据，包括故障码、实时数据流、服务信息等，使得所有参与方能够共享一致和准确的信息。版本2.0的数据模型规格明确了接口设计和数据结构，以便于诊断工具和硬件设备之间的互操作性。该规范的发布日期为2004年5月4日，由来自多个知名公司如T-Systems、BMW、GMSO、DSA、DaimlerChrysler、Siemens VDO等的专家共同编写和审阅。这些公司的代表包括Dr. Augustin、Dr. Hallermayer、Mr. Öhlenschläger等，他们确保了文档的权威性和技术准确性。ASAMe.V.许可Vector Informatik GmbH使用此规范，并允许下载者Henry.ge@vector.com在2014年10月14日获取此版本。然而，文档的免责声明指出，尽管尽最大努力制作，但不能保证文档完全无误或一致性，ASAMe.V.对文档内容和用途不承担任何明示或暗示的保证，特别是关于商品质量或适合特定目的的保证。这意味着用户在使用ASAM-MCD-2D(ODX)时，应自行验证其适用性和正确性，避免因潜在错误导致的问题。 ASAM-MCD-2D(ODX)-V2.0.0-ReleaseSpecification 是一个关键的行业标准，对于提升汽车行业ECU诊断和维修流程的效率，减少信息孤岛，以及促进技术更新和跨厂商合作具有重要意义。通过遵循这一规范，各利益相关者可以确保他们的工具和服务能够与市场上的其他系统无缝协作，从而提高整个产业链的竞争力。

10 ASAM MCD-2D (ODX)

5 Application of the Unified Modelling Language (UML)

5.1 General Aspects

The Unified Modelling Language (UML) has been recognized as the leading standard for object-oriented

systems design and data modelling. It is used within this standard to define the MCD 2D/ODX data model

formally and unambiguously. It also enhances the ease of understanding through graphical data model

diagrams.

Every reader of this standard may not know the UML. Therefore, a short introduction is given within this

chapter. Please note, that the following is not a complete description of the UML. Rather, those aspects of the

UML are described that are actually used within the MCD 2D/ODX data model. Specifically, from the large set

of available UML diagrams, we only apply class diagrams for data modelling within this standard.

5.2 Class Diagrams

5.2.1 Class

The central modelling element within the UML is a class. A class represents a set of similar real-world objects.

Generally, a class can be instantiated many times. Every instance of a class is called an object. A class has

attributes defining the properties of these objects and methods defining the actions an object can perform or

that can be performed on the object through another object. For this standard, methods are irrelevant and are

omitted from the description.

NAME[1] : String

AGE[1] : int

PROFESSION[0..1] : String

PERSON

Figure 6 — A UML class

Figure 6 — A UML class shows the representation of a class and its attributes within the UML notation. A

class is symbolized through a rectangle having one to three compartments. The top compartment contains the

name of the class, e.g. PERSON. The second compartment contains the attributes of the class, e.g. NAME,

AGE, PROFESSION. Methods are defined in an optional third compartment. The attribute- and method-

compartments do not have to be displayed. As the method-compartment is always empty within the MCD

2D/ODX data model diagrams, it is never displayed.

Attributes consist of the attribute name, e.g. NAME, followed by the attribute’s cardinality, e.g. [1] or [0..1] and

the attribute’s type, e.g. String. Furthermore, a default value for the attribute may be specified. Such a default

value follows the type descriptor of the attribute and is separated from it by the symbol =.

Throughout the MCD 2D/ODX data model, class names and attribute names are written in captial letters.

Licensed to Vector Informatik GmbH

Downloaded by henry.ge@vector.com on 14.10.2014

ASAM MCD-2D (ODX) 11

5.2.2 Inheritance Relationships

Classes can inherit attributes from other classes. In Figure 7 — Inheritance Relationship, a new class

SCHOOLKID is derived from the class PERSON. This means that implicitly the class SCHOOLKID has all the

same attributes as PERSON plus those that are defined specifically for the new class, e.g. GRADE. PERSON

is called the parent or super class; SCHOOLKID is called the child or subclass of the inheritance relationship.

Because the subclass adds more detail to the super class and is thus more specific, inheritance relationships

are often called “specializations”.

Inheritance relationships can be used to build inheritance trees of arbitrary depth. Any class within this tree

inherits all properties from those classes within the transitive closure of the inheritance relationship.

NAME[1] : String

«attr» AGE[1] : int

PROFESSION[0..1] : String

«attr» ID[1] : ID

PERSON

«attr» GRADE[1] : int

SCHOOLKID

«impl-parent»

Figure 7 — Inheritance Relationship

5.2.3 Interfaces

Interfaces are a special means to group certain aspects of a class and make other classes dependent only

one of these aspect groups, instead of the class as a whole.

An interface symbol looks identical to a class symbol. It can be distinguished from class through the

stereotype <<interface>> within the symbol’s name compartment.

Figure 8 — Interfaces contains a small example of how interfaces are used within a model. A class

COMPANY implements two interfaces: EMPLOYER and COMPETITOR. These are two roles of a company

as observed by different tester classes (i.e. an employee and a competing other company). A person being

employed by the company will not observe the company as a competitor. Equally, a competing company will

not observe the competitor as an employer. If a class implements an interface, a dashed arrow shows this,

similar to the inheritance arrow. A tester class of an interface (e.g. PERSON) may simply use associations or

aggregations to relate to an interface. It is important to know that the tester class (PERSON) may only use

those aspects of a class implementing the EMPLOYER interface that are defined within this interface.

Therefore, a company as may equally employ a person by an administrative body, because the latter also

implements the interface EMPLOYER.

Licensed to Vector Informatik GmbH

Downloaded by henry.ge@vector.com on 14.10.2014

12 ASAM MCD-2D (ODX)

NAME[1] : String

«attr» AGE[1] : int

PROFESSION[0..1] : String

«attr» ID[1] : ID

PERSON

«interface»

EMPLOYER

ADDRESS[1] : String

COMPANY

* 1

«interface»

COMPETITOR

ADMINISTRATIVE BODY

Figure 8 — Interfaces

5.2.4 Aggregation and Composition Relationships

Besides the inheritance relationship, a pair of classes may also have an aggregation or a composition

relationship between them. Aggregation or composition relationships are used, when an instance of one class

is contained within an instance of another class. They are drawn as a line with a diamond at the end of the

containing class. A composition relationship’s diamond is filled; an aggregation’s diamond is not.

The difference between these two kinds of so-called whole part relationships is as follows: The contained

element (the part) within a composition relationship is fully dependent on the containing element (the whole). If

the whole is deleted, the part may no longer exist. Therefore, a part may only belong to one whole, which

means it only has one incoming composition relationship. An aggregation relationship is one of shared parts.

This means, multiple wholes may own the same part. By consequence, the part’s life cycle is not dependent

on the whole’s life cycle

Figure 9 — Composition and Aggregation Relationships gives an example of three classes with composition

and aggregation relationships defined between them. A PERSON may have two feet (two instances of type

FOOT). A foot is generally very dependent on its owner. Therefore, a composition relationship is used. If the

PERSON no longer exists, the feet will neither. In contrast, a PERSON may also have a lot of COATs.

However, a COAT may generally be used by multiple people and it’s life-cycle is generally independent of the

life-cycle of one of its wearers. By consequence, the relationship between a PERSON and a COAT may be

modelled as an aggregation relationship.

Composition relationships may carry cardinalities as shown within the figure. The following cardinalities are

common within UML models:

1 Exactly one (single obligate)

0..1 Zero or one (single optional)

1..* One or many (multiple obligate)

0..* or * Zero or many (multiple optional)

Besides, any more specific cardinality may be specified, e.g. 5 or 2..8.

Cardinalities are read as follows: To know how many instances of class PERSON are related to one instance

of class FOOT, the cardinality at the PERSON end of the relationship is relevant. Vice versa: To know how

Please note that in the special case, where the data model is implemented in XML (see below), aggregation and

composition relationships are both mapped onto a sub element relationship between the two model elements. However,

the UML semantics guide prohibits multiple classes to have a composition relationship to the same class. Therefore,

aggregation relationships are used instead, even though the implementation in XML does not differ.

Licensed to Vector Informatik GmbH

Downloaded by henry.ge@vector.com on 14.10.2014

ASAM MCD-2D (ODX) 13

many instances of class FOOT may be related to one instance of class PERSON, the cardinality at the FOOT

end of the relationship is relevant. This yields the following result: One instance of class FOOT may be related

to exactly one instance of class PERSON (A foot always belong to one and only one person) and one

instance of class PERSON must be related to exactly two instances of class FOOT (a person usually has two

feet).

NAME[1] : String

«attr» AGE[1] : int

PROFESSION[0..1] : String

«attr» ID[1] : ID

PERSON

«attr» SIZE[1] : int

FOOT

1 2

«content» Brand[1] : String

COAT

Figure 9 — Composition and Aggregation Relationships

5.2.5 Association Relationships

The third kind of class relationship used within the MCD 2D/ODX data model is the association relationship. It

is drawn as a simple line between two classes. An association relationship has weaker semantics than the

composition relationship. Here, both classes have “equal rights”. An association relationship opens visibility

onto the properties (attributes, methods) of the related class. With composition relationships, an instance of a

composed class is only contained within one instance of the composing class. In contrast, instances of

associated classes may be related to many instances of other classes. To restrict the number of instances

being related to each other, cardinalities are used in the same manner as with composition relationships.

NAME[1] : String

«attr» AGE[1] : int

PROFESSION[0..1] : String

«attr» ID[1] : ID

PERSON

«attr» GRADE[1] : int

SCHOOLKID

«impl-parent»

MOTHER

Figure 10 — Association Relationship

Associations may carry a name and a role name can be given at every association end. In Figure 10 —

Association Relationship, the PERSON class carries the role MOTHER in a relationship to a SCHOOLKID.

The cardinalities state that a SCHOOLKID has exactly one mother, whereas a PERSON may be the

MOTHER or an arbitrary number of SCHOOLKIDs.

Licensed to Vector Informatik GmbH

Downloaded by henry.ge@vector.com on 14.10.2014

14 ASAM MCD-2D (ODX)

An association relationship may carry an arrow at one association end, which represents a navigation

direction, if applicable. This allows defining instances of which of the two classes may actually access

instances of the other class.

5.2.6 Association Classes

Association classes are a hybrid of an association and a class. Generally, they can be interpreted as an

association carrying its own attributes (and methods). They are drawn like an association with a class symbol

being connected to the centre of the association with a dashed line.

The example of a PERSON being employed by an EMPLOYER is modelled as an association class in

Figure 11 — Association Class. Here, the employment relationship is attributed with SALARY. This

employment-specific salary is clearly not a property of a PERSON, because one person may have multiple

salaries, if it is multiply employed. In addition, the salary may suddenly not exist, if the PERSON is

unemployed. It is also not a property of the EMPLOYER, because the EMPLOYER has many different

employee-specific salaries. This is the best indication that the SALARY is a property of an employment

relationship being established between a PERSON and an EMPLOYER.

NAME[1] : String

AGE[1] : int

PROFESSION[0..1] : String

PERSON

EMPLOYER

SALARY[1] : int

EMPLOYED

EMPLOYEE

Figure 11 — Association Class

5.2.7 Constraints

The UML allows defining constraints on the model elements used. Generally, constraints can be freely defined.

However, the MCD 2D/ODX standard only uses these features scarcely. One constraint that is used

frequently is the {xor} constraint between two associations (or aggregations). It enforces that an instance of

one class has a relationship with instances of one or the other associated class but never both at the same

time.

Licensed to Vector Informatik GmbH

Downloaded by henry.ge@vector.com on 14.10.2014

剩余449页未读，继续阅读

车载诊断技术

粉丝: 6534
资源: 693

ASAM MCD-2D ODX V2.0标准：汽车ECU诊断与编程数据交换规范

ASAM_MCD-2D（ODX）_Data_Model_Specification_V2.2.zip

ASAM_MCD-2D_ODX_V2.1.0.pdf

ASAM_MCD-2D（ODX）_Data_Model_Specification_V2.2.0_V2.1.0_V2.0.0.rar

ASAM-AE-MCD-2-D-BS-ODX-V2-2-0

TOC-ASAM-AE-MCD-2-D-BS-ODX-V2-2-0.pdf

ASAM_MCD-2MC_DataSpecifcation_V1.6.rar_ASAM mcd_ASAM-MCD-2MC_ASA

asam_ae_mcd-2d_v2.2.zip_ASAM MCD-2D_MCD 2D_asam mcd-2_asam3mc协议_

ASAM_MCD-2D（ODX）_Data_Model_Specification_V2.2.PDF

ASAM MCD-2D (ODX) 数据模型规范 V2.2

ASAM-AE-MCD-2-D-AuthoringGuidelines-AS-V1-0-0

最新资源