ODX Model

osoTEC: чтение и запись файлов ODX

В прошлый раз я рассмотрел конвертацию FRF файлов в файлы ODX, поэтому пора перейти к обработке непосредственно ODX файлов.

Что такое ODX?

Думаю, что очень немногие смогут дать правильный ответ на этот вопрос, но, надеюсь, что после прочтения этой записи у вас появится понимание что такое ODX и вы без труда ответите на него =)

Итак, ODX, в первую очередь, это модель данных. Да, не файлы как таковые с соответствующим расширением, а именно модель. Поэтому, если мы говорим о файлах, то мы понимаем, что данные в этих файлах соответствуют модели ODX. Вообще, ODX — это сокращение от Open Diagnostic Data Exchange, или, если дословно переводить на русский, «открытый обмен диагностическими данными».

Модель ODX была разработана ASAM (ассоциацией по стандартизации систем автоматизации и измерений) и закреплена в стандарте MCD-2D. В разработке стандарта MCD-2D участвовали такие компании как: Audi, BMW, Continental, Daimler, General Motors, Porsche, Renault, Bosch, Siemens, Volkswagen. Полное описание стандарта MCD-2D, описывающего модель ODX, можно найти в соответствующей спецификации ASAM MCD-2D.

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

Стандарт MCD-2D определяет модель данных (ODX) и формат описания, который не зависит от конкретных поставщиков, шин или протоколов и имеет четко определенную семантику для всех элементов спецификации.

Данные модели ODX сериализуются в формате XML в виде файлов с расширением ODX.

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

ODX-совместимый диагностический стек не только позволяет выполнять основные операции по диагностике ECU , но и делает доступными такие операции как считывание определенных внутренних сигналов, перепрограммирование, включение или отключение определенных функций ECU (кодирование) или определение текущей конфигурации ECU.

Чтобы предотвратить ошибки или неправильное использование, ODX предлагает несколько способов обеспечения целостности, достоверности и подлинности доступа к диагностическим данным.

Как читать/писать ODX файлы?

Учитывая, что одна из ключевых особенностей модели ODX это сериализация в XML, то, читать и писать ODX файлы очень просто. Все что требуется это написать реализацию модели ODX в виде объекта (класса). В нашем случае таким классом стал OdxXml.

С использованием объекта OdxXml, чтение любого ODX файла сводится к одной единственной строчке, где мы вызываем десериализацию объекта OdxXml (синтаксис приведен для C#):

OdxXml = (OdxXml)xmlSerializer.Deserialize(fileStream);

Запись данных в ODX файл будет выполняться также просто: достаточно выполнить сериализацию объекта OdxXml в файл:

xmlSerializer.Serialize(xmlWriter, OdxXml, namespaces);

Конечно, реализация класса OdxXml, соответствующего модели данных ODX, это, в некоторой степени, трудоемкая и сложная задача, особенно, если Вы хотите получить полную реализацию в соответствии со стандартом, но при этом пишите с нуля и не используете данные XSD. Элементов в модели ODX очень много, но каждый из них должен быть описан соответствующим объектом. Для сравнения приведу пример, при реализации SGO было создано всего 10 объектов, а в случае с ODX их было создано более 200!

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

Что дальше?

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

Чтобы получить гибкое решение, есть смысл отделить представление (ODX или SGO) от содержания (MED, EDC, DSG, панель приборов и т.д.) Во всяком случае в нашей реализации сделано именно так. Программный модуль ODX Manager, отвечающий за чтение/запись файлов ODX, никак не обрабатывает полезные данные, а просто передает их для дальнейшей обработки менеджеру полезной нагрузки (payload manager), например, в MED/EDC Manager

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

А пока это все, что мне хотелось рассказать про ODX.

Всем спасибо за внимание =)