ODX (ODX)

Перейти к навигации Перейти к поиску

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

Работа над стандартом 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 «Техническая диагностика. Термины и определения»