ODX

ODX (Open Diagnostic Data eXchange) — модель данных для описания диагностического обеспечения[1] транспортного средства посредством языка XML. Модель данных ODX создана для унификации представления диагностических данных в процессе разработки, производства и эксплуатации транспортного средства и определена стандартом ISO 22901-1:2008.

## Содержание

* 1 История
* 2 Область применения
* 3 Содержание
* 4 Примечания
* 5 Ссылки

## История[править | править код]

Работа над стандартом ODX началась в 2002 году группой специалистов ASAM. Первая версия стандарта была опубликована в 2004 году, она имеет название ASAM MCD-2D и является спецификацией формата ODX версии 2.0. Изначально формат ODX был предназначен для параметризации диагностических сканеров. ODX файл содержал всю информацию о диагностике отдельных электронных блоков управления и транспортного средства в целом.

Работа над стандартом продолжалась в последующие годы, так в 2005 году была разработана версия ODX 2.0.1, а в 2006 году ODX 2.1.0.

В дальнейшем к работе над стандартом подключается технический комитет Международной организации по стандартизации. В результате совместной работы в 2008 году создается ODX версии 2.2.0, который закрепляется стандартом ASAM и международным стандартом ISO 22901-1.

В 2011 году выходит вторая часть стандарта ISO 22901-2, которая определяет представление данных, связанных с выбросами транспортного средства, в рамках модели данных ODX. Данные о выбросах транспортного средства используются для контроля его состояния и пригодности к эксплуатации и ранее были заданы стандартами OBD.

В 2018 году выходит третья часть стандарта ISO 22901-3, которая определяет модель данных для представления алгоритмов обнаружения неисправностей в работе транспортного средства. Формат получил название FXD (Fault symptom eXchange Description), он также как и ODX использует XML. Данный формат позиционируется как средство представления логики обнаружения неисправностей, которую реализует электронный блок управления. Формат служит для обмена данными между производителями электронных систем автомобиля и автопроизводителями.

## Область применения[править | править код]

ODX предлагает единый способ представления данных, которые используются на всех этапах жизненного цикла автомобиля, такими его участниками, как производитель электронных блоков управления, автопроизводитель и сервисный центр. ODX предоставляет возможность автоматизировать часть операций на этапах разработки, производства и обслуживания автомобиля. Также ODX создает условия для повторного использования ранее созданных проектов и быстрого переноса с одной платформы на другую.

Рассмотрим основные случаи применения ODX каждым из участников жизненного цикла автомобиля:

Производитель электронных блоков управления использует ODX в следующих случаях:

* автоматическая конфигурация генератора кода для программного обеспечения электронных блоков управления,

* автоматическая конфигурация тестовых систем, которые используются при испытаниях электронных блоков управления,

* автоматическая генерация спецификации диагностического обеспечения электронных блоков управления,

* повторное применение, ранее созданного диагностического обеспечения в новых продуктах.

Автопроизводитель использует ODX в следующих случаях:

* создание исходных требований к диагностическому обеспечению в виде ODX,

* автоматическая конфигурация тестовых систем для проверки заявленного диагностического функционала электронных блоков управления,

* автоматическая генерация сервисной документации, в которой обычно отражается связь между выявленными неисправностями и их причинами.

Сервисные центры применяют ODX для параметризации диагностических сканеров во время обслуживания автомобиля.

## Содержание[править | править код]

Информация представленная в модели данных ODX разбита на блоки, которые называются пакетами. Назначение, содержание и взаимосвязи пакетов определено в рамках стандарта. Ниже приводится краткое описание основных пакетов.

Пакет | Описание

|

DiagLayerStructure |

Пакет DiagLayerStructure определяет иерархическую модель данных, которая включает четыре уровня:

* Protocol: коммуникационный протокол обмена данными, например KWP2000 или UDS.
* Functional Group: группа из нескольких ЭБУ в рамках одной подсистемы, например трансмиссия, шасси, кузов.
* Base Variant: данные общие для группы ЭБУ одного вида.
* ECU Variant: конкретный тип ЭБУ.

Данная модель также включает хранилище данных для общего доступа из разных уровней.

Comparam |

Пакет Comparam содержит параметры, которые определяют тайминги и логику поведения диагностического соединения. Параметры зависят от применяемого протокола. Они используются для настройки стека проколов внешних устройств, таких как D-servers. ODX обеспечивает определение коммуникационных параметров для KWP 2000 on CAN, KWP 2000 on K-Line и UDS on CAN.

VehicleInfo | Пакет VehicleInfo определяет данные, которые описывают автомобиль и доступ к его диагностическому интерфейсу. В первом случае это данные о производителе, модели и типе автомобиля. Во втором случае приводится описание цоколевки диагностического разъема, логической связи с контроллером шлюза или отдельного ЭБУ и описание протокола с его коммуникационными параметрами.
DataStream | Пакет DataStream определяет соединение между диагностическим тестером и ЭБУ на основе сервисов и процедур. Сервисы активируются диагностическим тестером посредством сообщений. Сообщение содержит SID (Service Identifier) и связанные значения параметров. ЭБУ отвечает сообщением. Это сообщение также содержит SID и параметры. Процедура используется для более сложных задач и содержит один или более сервисов. Сообщения в пакете DataStream определены на уровне битовой точности. Данные запрашиваемые из ЭБУ содержаться в сообщениях и могут быть закодированы. Данные могут быть интерпретированы и преобразованы к нужным физическим величинам посредством информации из DOP (data object properties).
DataParameter | Пакет DataParameter определяет простые и сложные объекты данных в диагностическом потоке данных. Простые объекты данных могут быть скалярными величинами или кодами неисправностей. Сложные объекты данных объединяют простые в виде структур, мультиплексированных данных, данных связанных с выбросами, полей и таблиц. Простые данные описаны посредством DOP, которые включают типы данных, методы преобразования (масштабирования), единицы измерения, границы диапазона и другие свойства. Пакет DataParameter также определяет "упаковку" данных в protocol data unit (PDU) и извлечение из него.
DynDefined | Пакет DynDefined содержит описание данных, которые могут быть определены во время работы - динамически определяемых данных. Такие данные включают в себя существующие значения. Этот метод соединения часто используется, когда конфигурация автомобиля может меняться во время или после производства. Кроме того, динамически определяемые данные позволяют объединять различную информацию в одно сообщение и передавать его по запросу диагностического сканера. Такой подход уменьшает нагрузку на шину передачи данных, так как вся необходимая информация передается одним сообщением. Данный пакет содержит информацию, используемую сервисами для определения и чтения динамически определяемых данных.
DataTypes | Пакет DataTypes содержит типы данных используемые при описании элементов UML модели данных. Этот пакет не определяет типы данных параметров.
SessionSecurity | Пакет SessionSecurity определяет конечный автомат, который обрабатывает два аспекта диагностического соединения:

* Условия выполнения диагностических сервисов или процедур.
* Состояния и условия перехода между состояниями в результате выполнения диагностических сервисов и процедур.

Эта модель определяет диагностические сессии, безопасные состояния и методы перехода между диагностическими сессиями и выполнения аутентификации доступа.

AdminInformation | Пакет AdminInformation обеспечивает информацию используемую при разработке диагностического обеспечения. Административная информация может быть прикреплена к каждому элементу модели данных. Она может содержать имя специалиста ответственного за данный элемент, информацию о его компании, историю ревизий элемента, данные связанные с системой управления версиями и специальные данные, определяемые компанией-разработчиком.

## Примечания[править | править код]

1. ↑ ГОСТ 20911-89 «Техническая диагностика. Термины и определения»

## Ссылки[править | править код]

* Christoph R., Klaus B. 2006 ODX in Practice. Experiences, challenges and potential, Technical Article, Vector Informatik GmbH
* Christoph R., Klaus B., Oliver G. 2011 The Standard Mix does it: Diagnostics with AUTOSAR and ODX — Part 2: ODX in the AUTOSAR Development Process, Translation of a German publication in Hanser Automotive, 11/2011
* Официальный сайт ISO
* Официальный сайт ISO в России
* ASAM MCD-2 D
* ISO 22901-2:2011
* ISO 22901-3:2018

У этой статьи не хватает нужной иллюстрации (модель данных ODX).

Вы можете помочь проекту, добавив её

|

На эту статью не ссылаются другие статьи Википедии.

Пожалуйста, установите ссылки в соответствии с принятыми рекомендациями.

|