Русская Википедия:ODX

Содержание

Текст

Текст

Текст

Текст

Текст

Текст

Текст

Текст

Текст

ODX (Open Diagnostic Data eXchange) — модель данных для описания диагностического обеспечения транспортного средства посредством языка 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 обеспечивает информацию используемую при разработке диагностического обеспечения. Административная информация может быть прикреплена к каждому элементу модели данных. Она может содержать имя специалиста ответственного за данный элемент, информацию о его компании, историю ревизий элемента, данные связанные с системой управления версиями и специальные данные, определяемые компанией-разработчиком.

Ссылки

• 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