ГОСТ Р 59891-2021 (ИСО 22901-3:2018). Национальный стандарт Российской Федерации. Автомобильные транспортные средства. Открытый обмен диагностическими данными (ODX). Часть 3. Описание обмена данными с симптомами отказов (FXD)
Актуально на 02.11.2026.
Как цитировать: "ГОСТ Р 59891-2021 (ИСО 22901-3:2018). Национальный стандарт Российской Федерации. Автомобильные транспортные средства. Открытый обмен диагностическими данными (ODX). Часть 3. Описание обмена данными с симптомами отказов (FXD)". ГОСТ Р 59891-2021. https://bukva.ai/docs/standart-gost-r-59891-2021
(утв. и введен в действие Приказом Росстандарта от 25.11.2021 № 1605-ст)
Примечание
Документ введен в действие с 01.04.2022.
Утвержден и введен в действие
Приказом Федерального
агентства по техническому
регулированию и метрологии
от 25 ноября 2021 г. № 1605-ст
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
АВТОМОБИЛЬНЫЕ ТРАНСПОРТНЫЕ СРЕДСТВА
ОТКРЫТЫЙ ОБМЕН ДИАГНОСТИЧЕСКИМИ ДАННЫМИ (ODX)
ОПИСАНИЕ ОБМЕНА ДАННЫМИ С СИМПТОМАМИ ОТКАЗОВ (FXD)
Automobile vehicles. Open diagnostic data exchange (ODX).
Part 3. Fault symptom exchange description (FXD)
(ISO 22901-3:2018, Road vehicles — Open diagnostic
data exchange (ODX) — Part 3: Fault symptom exchange
description (FXD), MOD)
(ИСО 22901-3:2018)
1 апреля 2022 года
Предисловие
1 ПОДГОТОВЛЕН Федеральным государственным унитарным предприятием «Центральный ордена Трудового Красного Знамени научно-исследовательский автомобильный и автомоторный институт „НАМИ“ (ФГУП „НАМИ“)»
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 056 «Дорожный транспорт»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 25 ноября 2021 г. № 1605-ст
4 Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО 22901-3:2018 «Дорожные транспортные средства. Открытый обмен диагностическими данными (ODX). Часть 3. Описание обмена данными с симптомами отказов (FXD)» (ISO 22901-3:2018 «Road vehicles — Open diagnostic data exchange (ODX) — Part 3: Fault symptom exchange description (FXD), MOD) путем изменения отдельных фраз (слов, ссылок), которые выделены в тексте курсивом. При этом приложения A, B, C, D полностью идентичны.»
Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5) и для увязки с наименованиями, принятыми в существующем комплексе национальных стандартов Российской Федерации
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)
Введение
Цель данного стандарта — определить новый формат описания обмена данными с симптомами отказов (FXD), который был разработан для предоставления машиночитаемых описаний преимущественно алгоритмов симптомов отказов, которые реализуются в виде диагностического программного обеспечения в электронном блоке управления.
Основной сценарий применения формата — передача данных от поставщика функций и программного обеспечения изготовителю транспортного средства в стандартизированном формате (XML-схема FXD), допускающем инструментальную (автоматизированную) обработку.
Поставщик программного обеспечения предоставляет исходные данные, связанные с программным обеспечением, которые должны быть расширены и уточнены изготовителем транспортного средства для различных случаев применения. На основе данных в формате FXD и соответствующих значений калибровки могут быть созданы несколько документов для конечного пользователя, например, «сводная таблица для документации бортовой диагностики».
Основными ожидаемыми преимуществами использования FXD являются повышение общей эффективности обмена данными, а также независимость от обработки форматов, специфичных для поставщика системы и изготовителя транспортного средства.
FXD является расширением ODX для поддержки документирования и обмена данными о симптомах отказов для одобрения типа транспортного средства и информации по ремонту и техническому обслуживанию.
Обязательное приложение включает в себя XML-схему FXD, представляющую модель данных для цифрового обмена данными бортовой диагностики (БД) в формате FXD.
Сложность систем мониторинга БД постоянно возрастает. Технический прогресс и обновления нормативных требований приводят к усложнению как самих систем двигателей, так и соответствующих систем мониторинга БД. Например, с течением времени значительно увеличилось количество мониторов и, следовательно, диагностических кодов отказов (DTC), как описано в настоящем стандарте, для 6-цилиндровых бензиновых двигателей с 2000 г. до 2012 г. (см. рисунок 1).
С увеличением количества мониторов БД возрастает их сложность.
На рисунке 1 показана возрастающая сложность систем БД.
1 — 6-цилиндровый бензиновый двигатель
Рисунок 1 — Возрастающая сложность систем
бортовой диагностики
Сложность современных проектов (например, наличие разных вариантов) у изготовителя транспортного средства является важным аспектом при создании диагностической документации. Для всех стратегий мониторинга, связанных с БД, разрабатывается соответствующая документация БД. Когда данные стратегии разрабатываются разными проектными командами, может потребоваться специальная адаптация и калибровка систем БД.
Для разработки качественной документации БД во всех проектах необходимы значительные усилия для синхронизации и ручной настройки. Очевидно, что такой конкретный подход имеет ограниченный потенциал повторного использования.
На рисунке 2 показана сложность проекта по разработке корректной документации БД.
Кроме того, более сложные бизнес-модели (распределение работы между несколькими компаниями) усложняют процесс документирования БД.
В прошлом, как правило, поставщик электронного блока управления также поставлял бульшую часть соответствующего программного обеспечения. В настоящее время и в еще большей степени в будущем с внедрением Autosar <1> будет усиливаться тенденция к появлению программных пакетов от изготовителя транспортного средства и сторонних поставщиков.
<1> Autosar (англ. AUTomotive Open System ARchitecture) — автомобильная архитектура открытых систем.
Как следствие, несколько поставщиков предоставляют информацию для создания документации БД в различных форматах, с разной структурой и содержанием данных. Для понимания функционирования систем БД часто необходимо углубляться в детали организации самой документации к программному обеспечению. Поэтому трудоемкость разработки и интеграции документации, связанной с БД, возрастает из-за ручного анализа и настройки. Очевидно, что этот сценарий допускает лишь ограниченное повторное использование.
На рисунке 3 показан возможный процесс распределения работ и согласования документации БД.
Ограничения планирования при создании документации БД на этапе разработки также представляют собой мотивирующий фактор для внедрения формата FXD. Поскольку масштабы БД становятся все обширнее, документация создается заблаговременно, но последующие изменения БД неизбежно приводят к необходимости многократной доработки документации. Без эффективного управления информацией, касающейся БД, невозможно решать сложные инженерные задачи в современных условиях жестких графиков выполнения работ.
1 Область применения
Настоящий стандарт определяет машиночитаемые описания всех алгоритмов симптомов отказов, которые реализованы в виде диагностического программного обеспечения (ПО) в электронном блоке управления (ЭБУ) транспортных средств (ТС). Основным назначением стандарта является внедрение стандартизированной передачи данных от поставщика функций и ПО к изготовителю ТС (ИТС) с целью обеспечения возможности инструментальной обработки передаваемой информации.
На основе данных в формате FXD и связанных с ними калибровочных значений могут быть сформированы несколько документов для конечного пользователя, таких как «сводная таблица», являющаяся необходимой частью пакета документации для одобрения типа ТС, или «информация по ремонту и техническому обслуживанию» (ИРТО). Ожидаемыми основными преимуществами использования FXD являются общее повышение эффективности обмена данными, а также независимость обработки от формата, специфичного для поставщика и ИТС.
Настоящий стандарт устанавливает правила для обмена информацией о симптомах отказов ЭБУ между поставщиком ПО ЭБУ и ИТС.
Настоящий стандарт определяет:
- содержание описания обмена симптомами отказов (FXD) для каждого симптома отказа;
- XML-структуру описания обмена симптомами отказов (FXD XML-схема);
- поддерживаемый вариант использования для обмена вышеупомянутым описанием.
2 Обозначения и сокращения
В настоящем стандарте использованы обозначения и сокращения, приведенные в [1] - [3], а также следующие сокращения:
DCY (driving cycle) — ездовой цикл;
DTC (diagnostic trouble code) — диагностический код отказа;
enum (enumeration) — перечисление;
FCM (fault code memory) — память для хранения кодов отказа;
FID (function identifier) — идентификатор функции;
FXD (Fault symptom eXchange Description) — описание обмена данными с симптомами отказов;
HDO (ASAM harmonized data objects) — гармонизированные объекты данных Ассоциации по стандартизации автоматизации и измерений;
MCL (monitoring checklist) — чек-лист мониторинга;
MIL (malfunction indicator light) — световой индикатор отказа;
OEM (original equipment manufacturer) — производитель оригинального оборудования;
OID (object identifier) — идентификатор объекта;
OSC (oxygen storage capacity) — объем кислородной емкости;
SENT (single edge nibble transmission) — протокол передачи данных от датчика к контроллеру с двухточечной схемой;
URI (uniform resource identifier) — унифицированный идентификатор ресурса;
W3C (world wide web consortium) — консорциум сети Интернет;
XML (extended mark-up language) — расширенный язык разметки.
3 Информация о версии спецификации
Версия спецификации FXD XML-схемы настоящего стандарта: 2.0.0.
4 Концепция FXD
4.1 Обзорная часть
В автомобильной промышленности определены требования к предоставлению информации, связанной с БД, и разработаны соответствующая концепция и формат.
Были сформулированы следующие основные задачи:
a) разработка машиночитаемого формата для автомобильной промышленности:
-
для одного источника описания симптомов отказа при различных случаях использования документации (например, информация об одобрении типа ТС, ИРТО) в разных вариантах проекта;
-
для осуществления обработки данных с использованием самых современных инструментов;
b) использование XML в качестве базовой технологии для определения формата (FXD XML-схема);
c) повторное использование структурных паттернов в соответствии с [4];
d) разработка наименований элементов структуры, которые должны соответствовать потребностям конечного пользователя.
4.2 Традиционный рабочий процесс
Традиционно информацией, относящейся к FXD, ИТС и поставщики ЭБУ обмениваются на основе собственных шаблонов и форматов.
Даже основные варианты использования FXD «одобрение типа ТС» и ИРТО управляются разными заинтересованными сторонами и приводят к несовместимым форматам и процессам обмена для одного и того же ИТС.
Поставщики ПО должны обрабатывать все разнообразие шаблонов и форматов с ограниченным повторным использованием и большим количеством ручной работы.
Интеграция и создание документов ИТС не могут быть автоматизированы из-за отсутствия стабильных и стандартизированных форматов данных.
4.3 Необработанные данные
4.3.1 Общее определение и предшествующее состояние
Используют абстрактное и структурированное описание всех условий/критериев/параметров, которые влияют на мониторинг процесса или стратегию. Должна существовать возможность обнаружения и устранения реального отказа с помощью теста, проведенного с использованием описания «необработанных данных».
Описание «необработанных данных» — это нейтральное описание, которое не должно быть смещено в сторону документации для конечного пользователя конкретного ИТС.
Описания «необработанных данных» требуют последующей ручной адаптации, чтобы отразить соответствующие требования ИТС, документации проекта и конечного пользователя.
За ручную адаптацию несет ответственность ИТС (см. 4.4).
4.3.2 Требования
4.3.2.1 Основные требования
Описания «необработанных данных» должны быть разработаны таким образом, чтобы обеспечить возможность автоматического анализа значений при вводе соответствующих калибровочных меток.
Описания «необработанных данных» должны относиться к соответствующей реализации ПО. Следовательно, необходима определенная абстракция программной реализации. Кроме того, формальные функции редактирования должны использоваться для улучшения читабельности (например, логическая группировка условий/использование заголовков, где это уместно). В качестве конкретных правил используют правила FXD.
Последовательность алгоритма обнаружения отказов должна быть описана с использованием формального языка. Этот формальный язык должен позволять автоматическую обработку информации, например, замену физических единиц, замену имен переменных (например, для разных языковых областей), замену меток калибровки и системных констант значениями, упрощение и частичную оценку выражений. Формальный язык должен обеспечивать визуализацию информации для различных пользователей. Когда формальное описание неосуществимо или нежелательно дополнительно должна быть обеспечена возможность описать алгоритмы на естественном языке (словесно).
4.3.2.2 Требования для генерации описания необработанных данных
Подробные требования определены в правилах генерации описаний FXD, приведенных в приложении C.
4.3.2.3 Требования к считывателям описания «необработанных данных»
Информация, представленная в описании «необработанных данных», должна позволять технически квалифицированному персоналу, обладающему общими знаниями о ТС, но не обладающему конкретными знаниями в области диагностики/БД, понимать физический процесс работы монитора.
- общие знания двигателя и ТС;
- общие знания по диагностике и БД;
- знание настоящего стандарта (формата FXD).
Поставщик не будет нести никакой ответственности в случае, если эти «необработанные данные» будут переданы другим потребителям (например, сертифицирующему органу, организации по послепродажному или сервисному обслуживанию). Файл FXD, предоставленный поставщиком, не будет содержать значений ссылочных калибровочных меток.
4.4 Формат FXD и пример
Основные задачи для XML-схемы FXD заключаются в удовлетворении требований документации «сводной таблицы БД».
Для обеспечения автоматического процесса публикации из формата FXD в «сводную таблицу БД» вся соответствующая информация должна быть представлена в формате FXD.
Симптом отказа является основным структурным критерием для «сводной таблицы БД». Вся информация, связанная с симптомом отказа, организована под соответствующим узлом внутри схемы FXD, который называется «FAULT-SYMPTOM».
Наиболее сложная информация в «сводной таблице БД» касается вложенных алгоритмических выражений для «MALFUNCTION-CRITERIA» и «ENABLE-CONDITIONS». Не требуется никаких структур управления, известных из языков программирования.
Пример выражения — <parameter_1(operand)> < greater than...(operator)> < threshold_1(operand)>
<parameter_2(operand)> < less than...(operator)> < threshold_2(operand)>
Операнды и операторы должны быть помечены отдельно в структуре XML, т.к. оба должны быть подготовлены для специфичной визуализации, например, публикации в разных графах таблицы.
Поскольку данные FXD, предоставляемые поставщиком ПО, будут содержать «необработанные данные», основанные на реализации ПО, необходима концепция уточнения для поддержки различных вариантов использования. Поэтому в FXD вводится принцип наследования, т.е. «необработанные данные», связанные с симптомом, могут быть уточнены для конкретного случая использования путем добавления уточненных информационных характеристик к данным FXD. Позже цепочка инструментов будет обрабатывать характеристики, специфичные для конкретного варианта использования.
«Необработанные данные» будут содержать имена, используемые в ПО, для параметров и метки калибровочных данных, например, для граничных значений. Для создания документации БД имена, используемые в ПО, должны быть заменены именами, понятными конечному пользователю, а метки калибровочных данных должны быть заменены соответствующими значениями. Оба механизма замены должны поддерживаться форматом FXD.
В дополнение к описанным выше требованиям при разработке схемы FXD были приняты во внимание следующие требования к содержанию:
- матрица блокировки;
- управление данными FXD на стороне ИТС (например, управление идентификаторами, ссылки на функции и спецификации ПО и т.д.);
- ИРТО (например, языковой атрибут).
На рисунке 4 показана сводная таблица БД в качестве одного из основных мотивов для определения формата FXD.
Рисунок 4 — Сводная таблица БД как один из основных мотивов для определения формата FXD
4.5 Базовая концепция FXD
4.5.1 Основные требования
Моделирование алгоритмических выражений является основной частью схемы FXD, поэтому требует детального объяснения.
После анализа содержимого сводных таблиц БД для алгоритмических выражений были сформулированы следующие требования:
- включить формальное описание вложенных алгоритмических выражений, основанных на программной реализации;
- включить формальные выражения (один операнд может быть текстовой строкой), которые не могут полностью соответствовать программной реализации, но необходимы для уменьшения сложности;
4.5.2 Формальное описание алгоритмов диагностики
Для описания условий, связанных с симптомами отказов, введен элемент COMPUTATION.
ABSTRACT-SYNTAX представляет дерево выражений, узлами которого могут быть:
a) оператор (или функция) OP с его аргументами (операндами) в качестве дочерних узлов (которые могут вновь являться деревом выражений);
b) переменная COMPU-VAR, которая состоит из ссылки DATA-DECLARATION-REF на переменную ЭБУ, параметр калибровки или системную константу;
c) константа COMPU-CONST, которая может представлять собой:
Смысл оператора OP определяется его атрибутом OPERATOR. Набор действительных операторов не указывается в самой XML-схеме FXD, а является цифровым приложением A к настоящему стандарту, чтобы обеспечить возможность его расширения без изменения схемы или изменения основного документа.
EXPLANATION состоит из неофициального описания DESC, допускающего несколько абзацев и некоторые стандартные возможности XHTML, и необязательного набора ссылок DATA-DECLARATION-REFS на переменную(ые) ЭБУ, параметр(ы) калибровки и системную(ые) константу(ы), которые позволяют декларировать зависимости от данных ЭБУ.
На рисунке 5 показаны элементы COMPUTATION и ABSTRACT-SYNTAX как базовые элементы FXD.
Рисунок 5 — Элементы COMPUTATION и ABSTRACT-SYNTAX в качестве базовых элементов FXD
4.5.3 Механизм наследования значений для поддержки вариантов использования
Варианты использования, указанные в 5.1 (см. рисунок 8), поддерживают возможность добавления в файл FXD специфических для конкретного варианта использования представлений симптомов отказов. Основным вариантом использования является «адаптация» критериев отказа (FAULT-DETECTION-CRITERIA) и вторичных параметров (ENABLE-CONDITIONS) ИТС для соответствия законодательным требованиям для создания документов, связанных с одобрением типа ТС. Другие варианты использования могут быть представлениями симптомов отказов на разных языках или для определенных групп пользователей.
Механизм наследования значений используется следующим образом.
Для каждого варианта использования может быть создан дополнительный экземпляр симптома отказа («дочерний симптом отказа»), имеющий то же имя (SHORT-NAME), что и у симптома отказа, являющегося «родительским симптомом отказа».
Каждый «дочерний симптом отказа» относится только к одному «родительскому симптому отказа». Разрешается ссылаться на базу симптомов отказов, указанную поставщиком, либо на другой существующий «дочерний симптом отказа».
Для «дочернего симптома отказа» все подэлементы являются необязательными, чтобы разрешить изменение только отдельных частей информации симптома отказа.
Вся информация, не указанная в «дочернем симптоме отказа», будет получена из его родительской иерархии.
«Дочерний симптом отказа» не должен определять обнаружение отказа с именем (SHORT-NAME), которое не определено его родителем. «Дочерний симптом отказа» может только переопределить унаследованные обнаружения отказов.
4.5.4 Реализация наследования значений
Механизм наследования значений применяется к элементам FAULT-SYMPTOM и VARIABLE-DESCRIPTION. Эти элементы имеют атрибут SI, который определяет вариант использования. Исходный элемент FAULT-SYMPTOM или VARIABLE-DESCRIPTION, из которого получены другие описания элементов, называется «базовый симптом отказа» или «базовое описание переменной». Вариант использования этих базовых элементов — «необработанная информация» (RAWINFO).
Для установления наследования значений FAULT-SYMPTOM или VARIABLE-DESCRIPTION должны содержать элемент PARENT-REF. PARENT-REF ссылается на родительский элемент, от которого наследуется FAULT-SYMPTOM или VARIABLE-DESCRIPTION. Родительский элемент и дочерний элемент должны иметь одно и то же SHORT-NAME.
Реализация наследования значений FXD в XML-схеме использует довольно необычную технику наследования по ограничению. XML-схема позволяет определять тип, ограничивая вхождения и содержимое элементов из типа, из которого он получен.
Базовый симптом или описание переменной должны содержать минимум информации, задаваемой необязательными элементами. Симптомы отказов или описания переменных, которые используют наследование значений FXD, содержат только те элементы, которые они переопределяют. В простейшем случае производный симптом отказа ничего не переопределяет, а наследует все свойства от своего родителя или предков. В этом случае элемент FAULT-SYMPTOM будет иметь только три дочерних элемента: SHORT-NAME, COMPANY-DATA-REF и PARENT-REF. Таким образом, XML-схема должна позволять всем остальным элементам производного элемента быть необязательными.
Решение состоит в том, чтобы использовать механизм XML-схемы «наследование по ограничению» путем определения базового типа симптома отказа (FAULT-SYMPTOM-BASE) и базового типа описания переменной (VARIABLE-DESCRIPTION-BASE). В результирующем FXD-XML-документе базовый элемент помечается атрибутом xsi:type=«FAULT-SYMPTOM-BASE» или xsi:type= «VARIABLE-DESCRIPTION-BASE».
4.6 Рабочий процесс FXD
Введение машиночитаемого и стандартизированного формата обмена для описания симптомов отказов позволяет усовершенствовать общий рабочий процесс.
Различные форматы и шаблоны будут заменены поставщиком ПО ЭБУ настоящим стандартом. Это позволит создать однородную цепочку инструментов и повторно использовать данные FXD. Поставщик ПО ЭБУ предоставит «необработанные данные», т.е. данные, которые основаны на реализации ПО, и эти данные будут уточняться ИТС в зависимости от варианта использования.
Для ИТС инструменты могут эффективно поддерживать следующие задачи, чтобы уменьшить ручное взаимодействие:
- интеграция данных FXD от разных поставщиков ПО ЭБУ;
- уточнение данных FXD для различных случаев использования (одобрение типа ТС, ИРТО);
- дополнение данных FXD значениями калибровки;
- создание документов конечного пользователя.
На рисунке 6 показан возможный рабочий процесс FXD.
Рисунок 6 — Возможный рабочий процесс FXD
4.7 Пример рабочего процесса FXD
Ниже показан пример возможного рабочего процесса FXD — выбор в качестве «разрешающего условия» симптома отказа «Заслонка впускного коллектора в цилиндре 1 заблокирована в открытом положении».
4.7.1 Шаг 1: Управление необработанными данными на стороне поставщика программного обеспечения электронного блока управления
Необработанные данные или вводятся в редакторе FXD, или извлекаются из существующих систем. Для управления информацией требуется специальный инструмент FXD (специализированное ПО). Необработанные данные основаны на именах, используемых в ПО, которые зависят от поставщика ПО.
Для элемента ABSTRACT-SYNTAX реализован набор правил, которые позволяют обеспечить обратную связь о проблемах в алгоритмических выражениях. Кроме того, рекомендуется реализовать такие возможности, как автозаполнение и проверка правильности имен ПО.
4.7.2 Шаг 2: Создание файла FXD-XML
После того как информация о симптоме отказа заполнена на стороне поставщика ПО ЭБУ, что является итеративным шагом в процессе разработки ПО, появляется возможность создать файл FXD по схеме FXD. Этот файл будет направлен ИТС.
4.7.3 Шаг 3: Интеграция и уточнение информации FXD на стороне ИТС
После получения информации FXD от поставщика ИТС приступает к интеграции деталей FXD в хранилище FXD. В зависимости от сложности алгоритма симптомов отказа необходимо уточнить описание для различных вариантов использования. Для выбранного примера уточнение не требуется, т.к. это простое разрешающее условие. Кроме того, для параметров ПО необходимо ввести описание для конкретного случая использования. В этом примере для исходного имени T_AST, используемого ПО, вводится описание «Время после запуска двигателя».
4.7.4 Шаг 4: Генерация сводной таблицы БД
После завершения шагов интеграции и уточнения информация готова к обработке для формирования документации конечного пользователя. Значение C_T_AST_MIN_PORT_DIAG будет получено из набора значений калибровки. Единица измерения (структурный паттерн, аналогичный используемому в [4]) является частью определения метки FXD. Наконец, процесс рендеринга будет использовать соответствующую информацию для публикации информации «Время после запуска двигателя > 15 с».
На рисунке 7 показаны этапы обработки для создания информации сводной таблицы БД.
4.8 Ограничения для обновлений схемы
Обновление XML-схемы FXD для соответствия новым требованиям может привести к необходимости обновления инструментария с обеих сторон, поставщика и ИТС. Кроме того, поставщикам может потребоваться поэтапное введение в эксплуатацию новых обязательных полей для генерирования новых описаний.
Чтобы обеспечить непрерывную работу с последней версией схемы, введен стандартный текст «пусто из-за перехода на новую схему».
Поставщики должны использовать стандартный текст «пусто из-за перехода на новую схему» для определения новых обязательных текстовых полей, которые не могут быть заполнены надлежащим описанием. Этот новый стандартный текст должен использоваться только в обязательных текстовых полях. Новые необязательные поля создаваться не должны.
5 Варианты использования FXD
5.1 Основные положения
На рисунке 8 показан основной поток информации и обзор вариантов использования.
Рисунок 8 — Основной поток информации и обзор вариантов использования
5.2 Вариант использования 1: Доставка «необработанных данных» поставщиками программного обеспечения электронного блока управления
В таблице 1 показан вариант использования 1.
Вариант использования 1: Доставка «необработанных данных» поставщиками программного обеспечения электронного
блока управления
| Название варианта использования | Вариант использования 1: Доставка «необработанных данных» поставщиками ПО ЭБУ |
|---|---|
| Цель | Поставка «необработанных данных» из версии ПО ЭБУ поставщиками ПО ЭБУ позволяет генерировать сводную таблицу БД на основе FXD и информацию о симптомах отказов для информации о послепродажном ремонте и обслуживании |
| Действующее лицо | Поставщик ПО ЭБУ |
| Входные данные | Версия ПО ЭБУ |
| Выходные данные | «Необработанные данные» FXD-XML, специфичные для версии ПО ЭБУ |
| Краткое описание | «Необработанные данные» о симптомах отказов предоставляются в виде так называемой «базы симптомов отказов». Такое представление симптома отказа может не подходить для разных случаев использования, специфичных для ИТС, поэтому могут быть добавлены дополнительные представления одного и того же симптома отказа. Более подробное описание используемого механизма приведено в 4.5.3 |
В дополнение к версии программы, поставляемой ИТС, поставщик может доставить соответствующий файл, содержащий согласованное описание симптомов отказа, поддерживаемое соответствующей версией программы. Этот файл будет называться файлом FXD.
Любая предоставленная информация должна рассматриваться как необработанные данные.
5.3 Вариант использования 2: Генерация документации на основе необработанных данных FXD
5.3.1 Вариант использования 2.1: Создание сводной таблицы БД для официального одобрения типа ТС
В таблице 2 приведена сводная таблица для варианта использования 2.1 «Генерация сводной таблицы БД для официального одобрения типа ТС».
| Название варианта использования | Вариант использования 2.1: Генерация сводной таблицы БД для официального одобрения типа ТС |
|---|---|
| Цель | Сгенерировать сводную таблицу БД из файла FXD в качестве документации для одобрения типа ТС |
| Действующее лицо | ИТС |
| Входные данные | - версия ПО; - версия данных; - «необработанные данные» FXD-XML, специфичные для версии ПО ЭБУ; - информация о запрете отношений между отдельными симптомами; - правовые требования; - другая необходимая информация |
| Выходные данные | Сводная таблица БД должна содержать: - имя компонента/системы; - законодательно закрепленный DTC; - код клиента (DTC); - код клиента (текст отказа (неисправности) клиента); - описание стратегии мониторинга; - критерии отказа; - пороговое значение; - вторичные параметры; - разрешающие условия; - подтверждение неисправности; - частота мониторинга; - информирование световым индикатором; и т.д. |
| Краткое описание | Информация, представленная в исходных данных, подготавливается в соответствии со спецификациями ИТС с учетом дополнительной входной информации (например, законодательных требований) и преобразуется в вид, понятный для уполномоченного органа. Затем ИТС заменяет метки приложений, использованные в исходных данных, значениями приложений в соответствии с конкретной программой и версией данных описываемого проекта (см. рисунок 11) |
5.3.2 Вариант использования 2.2: ИРТО, основанная на FXD
В таблице 3 указана ИРТО на основе варианта использования 2.2 FXD.
| Название варианта использования | Вариант использования 2.2: ИРТО на основе FXD |
|---|---|
| Цель | Генерация ИРТО на основе FXD в составе пакета публикации служебной информации ИТС для ремонта |
| Действующее лицо | ИТС |
| Входные данные | - версия программы; - версия данных; - необработанные данные FXD-XML, специфичные для версии ПО ЭБУ; - информация о запрете отношений между отдельными симптомами; - другая необходимая информация |
| Выходные данные | Инструкции по устранению отказов. Сервисный информационный лист должен содержать: - имя компонента/системы; - законодательно закрепленный DTC; - код клиента (DTC); - код клиента (текст отказа (неисправности) клиента); - описание стратегии мониторинга; - OK-DETECTION-CRITERIA; - пороговое значение; - вторичные параметры; - разрешающие условия; - OK-DEBOUNCE; - критерии отказа; - информирование световым индикатором; - замещающая функция; - функция защиты; и т.д. |
| Краткое описание | После завершения шагов интеграции и уточнения (см. 4.6) информация готова к обработке для создания документации конечного пользователя. В дополнение к информации об обнаружении отказов, обрабатывается также информация для службы по устранению отказов. Процесс рендеринга будет использовать соответствующую информацию для публикации информации, например, «Время после запуска двигателя > 15 с» |
6 Общие свойства элементов FXD
6.1 Атрибуты
Существует два вида атрибутов:
- содержание: атрибуты, которые поддерживают оценку содержимого соответствующего элемента FXD; эта информация используется для управления дальнейшей обработкой самой информации FXD;
- инфраструктура: атрибуты, которые используются для идентификации внутренней XML-структуры описания FXD.
Далее представлены существующие атрибуты.
6.1.1 Атрибут DESC_EXTENT (содержание)
В таблице 4 определены поддерживаемые значения атрибута DESC-EXTENT.
Атрибут DESC-EXTENT необходимо отличать от атрибута DESC-STATE. Атрибут DESC-STATE должен использоваться для идентификации описаний, разработка которых, с точки зрения автора, еще не завершена, и которые не приняли окончательный вид.
6.1.2 Атрибут HREF (содержание)
HREF идентифицирует внешний документ по URI. Если URI не является абсолютным (т.е. он не начинается со схемы), то вначале он устанавливается по базовому URI, определенному в xml:base, а затем — по URI текущего местоположения документа.
HREF=http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=60264.
Определяется для элемента EXTERNAL-DOC.
6.1.3 Атрибут ID (инфраструктура)
ID предоставляет внутренний XML-идентификатор для связанного элемента, который можно использовать для ссылки на этот элемент (см. 6.1.4).
- AUXILIARY-OBJECT;
- COMPANY-DATA;
- COMPUTATION;
- DATA-DECLARATION;
- FAULT-DETECTION;
- FAULT-SYMPTOM;
- FAULT-SYMPTOM-3RD-PARTY;
- FID;
- MASK;
- PHYSICAL-DIMENSION;
- SERVICE-06-ID;
- UNIT;
- VARIABLE-DESCRIPTION.
Значение ID должно соответствовать стандартному XML-типу xs:ID.
6.1.4 Атрибут ID-REF (инфраструктура)
Атрибут ID-REF используется для ссылки на другой элемент XML путем указания значения его атрибута ID (см. 6.1.3).
Например, ID-REF = «ID47110815».
- AUXILIARY-OBJECT-REF;
- COMPANY-DATA-REF;
- COMPUTATION-REF;
- DATA-DECLARATION-REF;
- FAULT-SYMPTOM-REF;
- FID-REF;
- MASK-REF;
- PARENT-REF;
- PHYSICAL-DIMENSION-REF;
- SERVICE-06-ID-REF;
- UNIT-REF.
6.1.5 Атрибут OID (содержание)
Атрибут OID используется для инвариантной идентификации элемента FXD, но не для связывания. Любой совместимый с FXD инструмент не должен изменять содержание OID (если оно есть) в течение всего жизненного цикла соответствующего элемента. Любая система, которая предоставляет возможности импорта/экспорта FXD в другом формате, должна обеспечивать поддержание OID в течение цикла импорта/изменения/экспорта. Поставщик несет ответственность за обеспечение уникальности OID. Поэтому рекомендуется использовать универсальные уникальные идентификаторы (UUID), описанные в [5].
Например, OID = «499848a3-d5a2-48d9-bd45-525c99e903b3».
6.1.6 Атрибут OPERATOR (содержание)
Атрибут OPERATOR указывает конкретный оператор FXD, который будет применен к дочерним элементам текущего элемента.
Например, OPERATOR = «duration_of».
Набор поддерживаемых значений состоит из всех указанных операторов FXD в соответствии с приложением A.
6.1.7 Атрибут SI (содержание)
Атрибут SI (семантическая информация) определяет семантическую характеристику связанного элемента.
В таблице 5 определены поддерживаемые значения атрибута SI.
6.1.8 Атрибут DESC-STATE (содержание)
Атрибут DESC-STATE указывает завершенность соответствующего элемента.
Например, DESC-STATE = «RELEASE».
В таблице 6 определены поддерживаемые значения атрибута DESC-STATE.
| Значение | Объяснение |
|---|---|
| INITIAL | Для первоначального описания |
| DRAFT | Для промежуточного описания |
| RELEASED | Для «финального» описания |
6.1.9 Атрибут TI (инфраструктура)
Атрибут TI (текстовый идентификатор) предоставляет внутренний XML-идентификатор для соответствующего текстового элемента, который предназначен для использования при указании альтернативных текстов/формулировок (например, на другом языке).
TI состоит из строки произвольных символов.
6.1.10 Атрибут VERSION (содержание)
Атрибут VERSION предоставляет номер текущей версии FXD-схемы в качестве единственного поддерживаемого значения. Таким образом, он определяет структуру и содержание соответствующего файла FXD.
Атрибут VERSION состоит из трех чисел «x.y.z»: «x» — будет увеличено в случае несовместимых изменений, «y» — будет увеличено в случае совместимых изменений (например, удалены или добавлены только необязательные элементы), «z» — увеличивается для исправления ошибок.
Прежние документы становятся недействительными по отношению к новой версии схемы, поскольку, по меньшей мере, изменился номер версии FXD. Приложения должны рассмотреть эту проблему и решить, принимать документ FXD или не принимать.
Определяется для элемента FAULT-SYMPTOM-EXCH-DESC.
Указанная версия схемы должна использоваться для проверки файла FXD.
6.1.11 Атрибут xml:base (инфраструктура)
Атрибут xml:base — это рекомендованное W3C средство для определения базовых URI для частей XML-документов.
Определяется для элемента FAULT-SYMPTOM-EXCH-DESC.
6.1.12 Атрибут xml:lang (инфраструктура)
Атрибут xml:lang используется для указания естественного языка, на котором задано содержимое связанного элемента.
Поддерживаемые значения приведены в http://www.iso.org/iso/home/standards/language_codes.htm.
6.1.13 Атрибут xsi:nil (содержание)
Атрибут xsi:nil используется для разрешения пустого содержимого в обязательных элементах. Он разрешен для следующих элементов и имеет следующую семантику:
- CUSTOM-KODES/пользовательский код отсутствует;
- ENABLE-CONDITIONS/не существует разрешающего условия;
- FAULT-DEBOUNCE/не существует подтверждения отказа;
- LEGAL-CODE/правовой код не существует;
- LEGISLATIONS/законодательные ограничения отсутствуют;
- OK-DEBOUNCE/имеет такое же содержание, как FAULT-DEBOUNCE;
- OK-DETECTION-CRITERIA/логическая инверсия содержания FAULT-DETECTION-CRITERIA;
- OK-ENABLE-CONDITIONS/имеет такое же содержание, как ENABLE-CONDITIONS.
Чтобы задействовать этот атрибут, соответствующий элемент должен иметь атрибут nillable <1>, настроенный на значение «истина» в соответствующем определении схемы.
<1> Атрибут nillable указывает на возможность присвоения элементу явного значения NULL.
6.1.14 Атрибут xsi:type (инфраструктура)
Атрибут xsi:type должен использоваться для указания правильного типа XML в схеме в случае неясностей. В данном случае необходимо выбрать базовый тип для наследования симптомов отказов и описания переменных с помощью атрибута SI, установленного в RAWINFO.
Он определен для следующих элементов со следующими значениями:
- FAULT-DETECTION/@xsi:type=«FAULT-DETECTION-BASE»;
- FAULT-DETECTIONS/@xsi:type=«FAULT-DETECTIONS-BASE»;
- FAULT-SYMPTOM/@xsi:type=«FAULT-SYMPTOM-BASE»; а также
- VARIABLE-DESCRIPTION/@xsi:type=«VARIABLE-DESCRIPTION-BASE».
6.2 Вариантное кодирование
Допускаются следующие типы вариантного кодирования:
- в зависимости от значения метки калибровки в ПО активируются разные алгоритмы. Эти условия будут предоставлены как часть COMPUTATIONS (например, на которые ссылается ENABLE-CONDITIONS) в файле FXD;
- в зависимости от значения метки внутренней калибровки функции алгоритмы могут быть активированы или деактивированы. Эти метки описаны в выделенном элементе, подробнее см. DISABLE-REPORT-ONLY (см. 7.6.11.13) и DISABLE-FULLY (см. 7.6.11.14);
- для одной версии программы существует несколько наборов калибровочных данных, что означает, что одна калибровочная метка может представлять разные значения для разных наборов данных: файл FXD, предоставленный поставщиком, будет содержать только общие названия калибровочных меток, поэтому этот вариант использования не рассматривается.
6.3 Реестры общего выбора
Для нескольких информационных элементов значения должны быть получены из реестров общего выбора (в соответствии с приложением B):
- MON_COMPONENT;
- MON_FREQUENCY;
- READINESS_GROUP;
- RATIO_GROUP;
- MCL_STRATEGY (ссылка на законодательство/нормативную базу);
- SIMULATION_METHOD;
- GENERIC_TYPE.
Реестры общего выбора должны иметь номера версий.
Ограничения для содержимого реестра выбора:
- существующие значения из всех более старых версий должны оставаться в силе;
- новые версии не должны применяться к существующим данным.
В соответствии с различными приведенными примерами должны поддерживаться пробелы и специальные символы.
Таким образом, произвольные строки будут поддерживаться без дополнительной разметки для всех реестров выбора в схеме.
6.4 Ссылки на внешние документы
Если необходимо, из элементов DESC и RESOURCES допускается ссылаться на произвольное количество внешних документов (например, изображений, сложных описаний), используя необязательную структуру EXTERNAL-DOCS.
6.5 Ссылки на переменные ЭБУ и калибровочные метки
Для ссылки на переменные ЭБУ или метки калибровки введен элемент DATA-DECLARATION. Элемент DATA-DECLARATION содержит имя переменной или метки калибровки, включая «[...]» для доступа к элементу массива и «.» для доступа к подструктуре, если требуется, например, «DSM.DFC_test».
Примечание — В случае вариантов калибровочных меток с кодовым обозначением будет указано только общее название, см. 6.2.
Дополнительная информация о метках должна быть получена из файла «a2I», если необходимо, например, физические единицы, метки осей кривых и карт.
При необходимости можно ссылаться на каждый элемент DATA-DECLARATION, используя DATA-DECLARATION-REF. Это позволяет осуществлять множественные ссылки на один и тот же элемент DATA-DECLARATION для повторного использования.
6.6 Общие элементы FXD, используемые для идентификации и описания
Следующая группа элементов FXD используется для уникальной идентификации основных элементов алгоритма диагностического ПО. В основном это переменные, параметры калибровки и параметры конфигурации (системные константы), симптомы отказов, описания переменных и FID.
- SHORT-NAME: обязательный идентификатор в соответствии со спецификацией ASAM HDO SHORT-NAME;
- LONG-NAME: необязательный элемент, содержащий воспринимаемое человеком имя в соответствии со спецификацией ASAM HDO LONG-NAME;
- DESC: необязательный элемент для получения дополнительной информации.
Эта группа элементов указывается как «Element-Id».
7 Описание элементов FXD
7.1 Основные положения
В 6.2 - 7.4 описаны элементы схемы FXD, определяющие общую информацию, необходимую, например, для обмена файлами FXD.
7.2 Элемент ADMIN-DATA
7.2.1 Основные положения
Элемент ADMIN-DATA моделируется аналогично элементу ODX с тем же именем, но для указания информации, специфичной для проекта (см. 7.2.2 - 7.2.6), необходимы некоторые расширения.
7.2.2 Элемент COMPANY-DATA-REF
В рамках COMPANY-DATA-REF компания, предоставляющая файл FXD (см. 6.3), указывается атрибутом ID-REF.
7.2.3 Элемент ECU-FAMILY
Необходимо ввести семейство блоков управления, чтобы определить тип блока управления, для которого создаются описания.
7.2.4 Элемент PROJECT
Этот элемент используется для идентификации проекта. Проект будет указан по имени (NAME) и его версии (SW-BASELINE).
7.2.5 Элемент RESOURCES
Элемент RESOURCES должен использоваться для идентификации специфичных для проекта файлов, которые используются в качестве базы данных для файла FXD:
- элемент DATA-DESCRIPTION должен содержать ссылку на ресурс описания данных, например, файл «a2I» (обязательно);
- элемент CALIBRATION должен содержать ссылку на набор калибровочных данных (необязательно);
- элемент EXTERNAL-DOCS может содержать ссылки на используемые дополнительные файлы. Каждый EXTERNAL-DOC предоставляет текстовое объяснение документа и ссылку на него атрибутом HREF.
7.2.6 Элемент DOC-REVISIONS
Элементы DOC-REVISIONS являются подмножеством того же элемента в соответствии с [4].
Данная информация используется для различия разных выпусков файла FXD для одной версии программы.
Каждый элемент DOC-REVISIONS состоит из:
a) REVISION-LABEL: необязательное текстовое поле для указания версии;
b) STATE: обязательный элемент для указания степени завершенности по заранее заданным значениям схемы:
c) DATE: обязательный элемент для указания даты доставки.
7.3 Элемент COMPANY-DATAS
7.3.1 Основные положения
В данном элементе указывают информацию обо всех компаниях, ответственных за содержание файла FXD (например, имя, задействованный персонал). Это подмножество того же элемента ODX (см. [4]). Для каждой компании предоставляется один элемент COMPANY-DATA.
7.3.2 Элемент COMPANY-DATA
Элемент COMPANY-DATA состоит из следующих элементов, идентифицирующих компанию и ее участников:
- Element-Id (см. 6.6);
- TEAM-MEMBERS: необязательный элемент для предоставления информации о членах компании (подробнее см. [4]).
Примечание — Поставщики ПО ЭБУ будут предоставлять информацию только о компаниях.
7.4 Элемент DATA-DICTIONARY
7.4.1 Элемент DATA-DECLARATIONS
Элементы DATA-DECLARATIONS используются для описания внутренних переменных ЭБУ, типов данных калибровки и системных констант.
Каждый элемент DATA-DECLARATIONS состоит из:
a) Element-Id (см. 6.6);
b) DATA/DATA-NAME: обязательный элемент, содержащий имя «a2I» DATA-DECLARATION;
c) DATA/DATA-TYPE: обязательный элемент для указания типа одним из следующих предопределенных значений схемы:
-
CALIBRATED (для калибровочных данных, подлежащих замене при создании сводных таблиц);
-
CALIBRATION-INFO (данные калибровки, которые используются для информации и не должны заменяться ее значениями);
-
NON-CALIBRATABLE (некалибруемые константы, например, системные константы);
d) DATA/DISPLAY-NAME: необязательный элемент для предоставления DISPLAY_IDENTIFIER из файла «a2I»;
e) DATA/DATA-VALUE: необязательная структура для предоставления логического (VB), числового (V) или текстового (VT) значения вместе с необязательной (см. перечисление a) 7.4.1) физической единицей (через UNIT-REF).
Элемент DATA-DECLARATION ссылается на одно или несколько вычислений. Этот список введен для повторного использования DATA-DECLARATIONS. Предварительным условием для DATA-DECLARATIONS является то, что внутренние переменные и данные калибровки уникальны в своем контексте (файл «a2I»).
7.4.2 Элемент COMPUTATIONS
Элемент COMPUTATIONS используется для описания алгоритма вычислений в формальной или текстовой/устной форме.
Элемент COMPUTATIONS состоит из Element-Id (см. 6.6), а также одного из двух элементов:
- ABSTRACT-SYNTAX: формальное синтаксическое дерево, состоящее из операторов и операндов; операнды могут быть константами (COMPU-CONST) или переменными (COMPU-VAR, ссылающимися на DATA-DECLARATIONS);
- EXPLANATION: текстовое описание, воспринимаемое человеком. Этот вариант можно использовать, когда ABSTRACT-SYNTAX будет слишком сложным или желательно более неформальное описание, удобное для человека. Он также может быть полезен, если будет приведено не детальное описание, а только общее назначение алгоритма.
В любом случае переменные и параметры калибровки и т.д., которые используют алгоритм, должны быть перечислены в элементах DATA-DECLARATION-REF. Это помогает понять функциональные отношения между различными переменными.
Рисунок 9 визуализирует выражение ABSTRACT-SYNTAX (N>C_N_Thr+1000 об/мин).
Рисунок 9 — Визуализация выражения ABSTRACT-SYNTAX
Важно отметить, что вычисления FXD не обязаны оцениваться. Вполне допустимо определить вычисление, которое будет иметь форму (в псевдокоде): sqrt («некоторая неизвестная функция»). Это связано с тем, что основной целью FXD является описание функций, функциональных отношений, условий и алгоритмов для использования в документации. Тем не менее вычисления FXD должны быть как можно более формальными, чтобы позволить автоматическую обработку. Этот подход имеет несколько существенных преимуществ:
- FXD-вычисления могут быть частично оценены. Например, метки калибровки могут быть заменены значениями, а части вычислений (поддеревья абстрактного синтаксиса) могут быть сокращены;
- все вычисления могут быть преобразованы так, чтобы заменять переменные или физические единицы. Например, условие V32 > 100 км/ч может быть автоматически преобразовано в «текущую скорость» более 62 миль/ч;
- могут быть обнаружены несоответствия и циклические зависимости;
- FXD-вычисления могут быть дополнительно обработаны, главным образом для визуализации.
7.4.3 Элемент UNIT-SPEC
Данный элемент введен для повторного использования физических единиц. На них ссылается формула вычисления, если это необходимо для постоянных значений.
Элемент UNIT-SPEC, включая UNIT-GROUPS, UNITS и PHYSICAL-DIMENSIONS, определяется как подмножество соответствующего элемента (см. [4]).
Примечание — Физические единицы измерения переменных и меток калибровки неявны и должны быть получены из файла «a2I».
7.5 Элемент VARIABLE-DESCRIPTIONS
7.5.1 Основные положения
Элемент VARIABLE-DESCRIPTION используется для подробного описания вычисления переменной ЭБУ (в FXD, представленной DATA-DECLARATION с DATA-TYPE, установленным в «ONLINE»). Внутри схемы элемент VARIABLE-DESCRIPTION расположен на том же уровне, что и элемент FAULT-SYMPTOMS. Он также включает ту же метаинформацию (COMPANY-DATA-REF, ECU-FUNCS, CONFIGURATION и атрибуты: DESC-EXTENT, DESC-STATE, ID, OID, SI, xml: lang).
Элемент VARIABLE-DESCRIPTION поддерживает три различных типа переменных:
- SIMPLE-VARIABLE: один COMPUTATIONS;
- BIT-FIELD-VARIABLE: COMPUTATION для каждого содержащегося BIT-FIELD;
- STATE-GRAPH: определение STATES и COMPUTATIONS для каждого поддерживаемого STATE-TRANSITION.
Элементы VARIABLE-DESCRIPTIONS подчиняются тому же механизму наследования значений, что и элементы FAULT-SYMPTOM. Для этого есть элемент PARENT-REF (см. 4.5.4).
Если VARIABLE-DESCRIPTION наследуется от другого VARIABLE-DESCRIPTION, тип переменной не должен изменяться. Кроме того, полная информация о типе переменной может быть перезаписана только целиком.
7.5.2 ID элемента
Ключ описания переменной: уникальное имя, указанное поставщиком, описанное в соответствии с 6.6.
7.5.3 Элемент COMPANY-DATA-REF
Этот элемент содержит ссылку на компанию, предоставляющую VARIABLE-DESCRIPTION.
7.5.4 Элемент ECU-FUNCS
В данном пункте указаны имена и версии ECU-FUNC, которые способствуют вычислению описанной переменной.
Каждый ECU-FUNC состоит из двух элементов, описанных ниже.
7.5.4.1 Элемент LONG-NAME
Это специфичное для поставщика имя ECU-FUNC в соответствии со спецификацией HDO LONG-NAME, указанной в файле «a2I».
7.5.4.2 Элемент VERSION
Этот элемент содержит версию ECU-FUNC, заданную в элементе «a2I» FUNCTION_VERSION для функции, вычисляющей описанную переменную.
7.5.5 Элемент CONFIGURATION
Этот элемент содержит ссылки на DATA-DECLARATIONS, представляющие некалибруемые константы («системные константы»), которые влияют на вычисление описанной переменной.
7.5.6 Элемент DATA-DECLARATION, описываемый элементом VARIABLE-DESCRIPTION
Этот элемент содержит ссылку на элемент DATA-DECLARATION, который описывается элементом VARIABLE-DESCRIPTION.
7.5.7 Элемент SIMPLE-VARIABLE
Элемент SIMPLE-VARIABLE используется, если переменная (например, байт или даже один бит) представляет одно физическое значение, которое не является состоянием (конечного автомата). Для этого варианта использования вычисление описывается одним элементом COMPUTATION.
7.5.8 Элемент BIT-FIELD-VARIABLE
Если значение переменной не представляет отдельное значение, но отдельные биты или битовые поля представляют независимые значения (т.е. флаги), используется элемент BIT-FIELD-VARIABLE.
Элемент BIT-FIELD-VARIABLE состоит из элементов BIT-FIELD, каждый из которых представляет одно физическое значение. BIT-FIELD определяется:
Примечание — BIT-FIELD-COMPUTATION возвращает значение для описываемого битового поля, но оно не будет выровнено в соответствии с положением битового поля.
Пример — Если описан один бит, BIT-FIELD-COMPUTATION вернет 0/1 независимо от того, в какой битовой позиции определен соответствующий бит.
7.5.9 Элемент STATE-GRAPH
Если переменная представляет состояния конечного автомата, используется элемент STATE-GRAPH.
- STATES: список поддерживаемых значений состояния переменной, использующий элементы DATA-DECLARATION-REF, ссылающийся на элементы DATA-DECLARATION типа DATA-TYPE 'STATE-VALUE';
- INITIAL-STATE: задает начальное состояние, используя элемент DATA-DECLARATION-REF, ссылающийся на элемент DATA-DECLARATION типа DATA-TYPE 'STATE-VALUE';
- STATE-TRANSITIONS: состоит из произвольного числа элементов STATE-TRANSITION, определяя:
- FROM-STATE (ссылка на DATA-DECLARATION);
- TO-STATE (ссылка на DATA-DECLARATION);
- REQUIRED-CONDITION (ссылка на определяющие условия COMPUTATION, которые должны быть выполнены для перехода из одного состояния в другое);
- STATE-COMPUTATION: возможность указать вычисление документированных значений состояния из внутренних значений переменной граф состояния, если между двумя битами нет полного соответствия (например, маскирование и сдвиг выделенных битов, в этом случае переменная графа состояния реализована как битовое поле).
Примечание — Элементы DATA-DECLARATION-REF в INITIAL-STATE, FROM-STATE, TO-STATE указываются в элементе STATES.
7.6 Элемент FAULT-SYMPTOMS
7.6.1 Основные положения
В данном подпункте описываются элементы FXD-схемы, определяющие информацию, специфичную для симптомов отказа.
Примечание — Симптомы отказа в версии программы, предоставленной сторонними организациями, будут описаны отдельно (см. 7.7).
7.6.2 ID элемента
Ключ описания (на основе симптомов отказа): уникальное имя симптома отказа, указанное поставщиком, описанное в соответствии с 6.6.
Примечание — Короткое имя (SHORT-NAME) элемента FAULT-SYMPTOM должно соответствовать элементу FAULT-SYMPTOM-NAME файла «a2I».
7.6.3 Элемент COMPANY-DATA-REF
Этот элемент содержит ссылку на компанию, предоставившую FAULT-SYMPTOM.
7.6.4 Элемент ECU-FUNCS
В данном пункте указаны имена и версии ECU-FUNC, которые способствуют обнаружению симптома отказа. Приложение C содержит список функций/версий.
7.6.4.1 Элемент LONG-NAME
Данный элемент содержит указанное поставщиком имя ECU-FUNC в соответствии со спецификацией HDO LONG-NAME, указанной в файле «a2I».
7.6.4.2 Элемент VERSION
Данный элемент содержит версию ECU-FUNC, указанную в элементе «a2I» FUNCTION_VERSION для функции диагностики.
7.6.5 Элемент CONFIGURATION
Данный элемент содержит ссылки на DATA-DECLARATIONS, представляющие некалибруемые константы («системные константы»), которые влияют на расчет описанного симптома отказа.
Кроме того, значение каждой системной константы должно быть указано в соответствующем элементе DATA-VALUE. Более подробная информация содержится в приложении C.
7.6.6 Элемент FAULT-IDENTIFICATION
7.6.6.1 Правовой код
Код отказа, требуемый законодательством, предоставляется как ссылка на вычисление, которое может быть значением, меткой либо меткой с индексацией, которая может быть задана. В таблице 7 определен FAULT-CODE внешнего испытательного оборудования.
FAULT-CODE внешнего испытательного оборудования
7.6.6.2 Элемент CUSTOM-CODES
Специфичный для клиента код предоставляется как ссылка на вычисление, в котором можно указать значение, метку либо метку с индексацией. В дополнение к этому тип CUSTOM-CODE может быть указан для обеспечения различия между разными CUSTOM-CODES. В таблице 8 определен сервисный код отказа.
7.6.6.3 Элемент FAULT-TYPE
Каждый симптом отказа может быть поставлен в соответствие коду отказа (DTC), и, кроме того, для соответствующего симптома отказа для удобства технического обслуживания могут быть предусмотрены дополнительные отличительные признаки. Классификация типов отказов приведена в [3]. В таблице 9 определен элемент FAULT-TYPE.
7.6.7 Элемент MON-COMPONENT или система
Данный элемент представляет краткое описание MON-COMPONENT или системы.
Пример — Датчик 1 положения педали акселератора.
В таблице 10 определены элемент MON-COMPONENT или система.
| Ссылка на сводную таблицу БД | Компонент/система |
|---|---|
| Формат | Текстовое поле с символами ASCII |
| SELECTION-LIST-NAME | MON_COMPONENT |
7.6.8 Элемент FAULT-CLASSIFICATION
Данный элемент состоит из элементов ERR-CLASS или MIL-RELEVANCE и необязательного элемента MIL-DEBOUNCE-GROUP.
7.6.8.1 Элемент ERR-CLASS
Этот элемент содержит информацию о связи между предупреждением водителя (MIL, EPCL/SYS и т.д.) и приоритетом.
В таблице 11 определен элемент ERR-CLASS.
7.6.8.2 Элемент MIL-RELEVANCE
Данный элемент содержит информацию о том, должен ли описанный элемент FAULT-SYMPTOM включать световой индикатор БД.
В таблице 12 определен отказ элемента MIL-RELEVANCE (относящегося к световому индикатору).
7.6.8.3 Элемент MIL-DEBOUNCE-GROUP
Если совместное устранение неполадок MIL становится необходимым для нескольких элементов FAULT-SYMPTOMS с FCM, основанной исключительно на элементах FAULT-SYMPTOMS, и, если это было согласовано с омологацией, эти элементы FAULT-SYMPTOMS могут быть назначены одной группе MIL.
В таблице 13 определен элемент MIL-DEBOUNCE-GROUP.
7.6.9 Элемент RATIO-GROUPS для применения в коэффициенте использования монитора (IUMPR)
Для элемента FAULT-SYMPTOMS из групп компонентов, которые должны выводиться как IUMPR через службу 0916 в соответствии с законодательством БД, должны быть назначены элементы RATIO-GROUP.
Элементы RATIO-GROUP следует вводить из реестра выбора (см. C.3.4). Поддерживаются несколько назначений.
В таблице 14 определен элемент RATIO-GROUP.
7.6.10 Элемент READINESS-GROUP
Данный элемент используют для документирования распределения элементов FAULT-SYMPTOM в отношении статуса готовности (Сервис 0116, PID 0116) и статуса мониторинга (Сервис 0116, PID 4116). В таблице 15 определен элемент READINESS-GROUP.
7.6.11 Элемент FAULT-DETECTIONS
7.6.11.1 Основная информация FAULT-DETECTION
Поскольку для симптома отказа может существовать несколько стратегий обнаружения отказа, для каждой из них должен быть предусмотрен отдельный элемент FAULT-DETECTION. В дальнейшем описываются подэлементы одного элемента FAULT-DETECTION.
7.6.11.2 ID элемента
Ключ описания обнаружения отказа: специфическое для поставщика уникальное имя обнаружения отказа, описанное в соответствии с 6.6.
7.6.11.3 Элемент MON-STRATEGY
Данный элемент обеспечивает грубую классификацию основного алгоритма обнаружения отказов.
В таблице 16 определен элемент MON-STRATEGY.
| Ссылка на сводную таблицу БД | Описание стратегии мониторинга |
|---|---|
| Формат | Текстовое поле с символами ASCII |
| Дополнительная информация | Должны использоваться термины, основанные на MCL |
Для рациональности и функциональных проверок из описания должно быть понятно, как используемая стратегия работает для соответствующего компонента. Недостаточно просто ввести такие термины, как «проверка рациональности».
Должны быть использованы такие термины, как:
- проверка функционального состояния: заслонка закрыта;
- проверка на рациональность: ее невозможно открыть;
7.6.11.4 Элемент FAULT-DETECTION-CRITERIA
Данный элемент содержит описание критериев обнаружения отказов, которое определяется следующим образом:
Это решение может быть предварительным в том смысле, что может быть необходима последующая фаза подтверждения для проведения различия между фактическим отказом и его ошибочным обнаружением. Эта подтверждающая фаза обычно называется «подтверждение» (debounce).
Каждое условие, которое должно быть выполнено как предварительное условие, чтобы решение могло быть вычислено, не относится к FAULT-DETECTION-CRITERIA. Это разрешающие условия (или условия проверки).
Дополнительная информация содержится в приложении C.
В таблице 17 определен элемент FAULT-DETECTION-CRITERIA.
| Ссылка на сводную таблицу БД | Критерий отказа/пороговое значение |
|---|---|
| Формат | Реализуется как ссылка на вычисление (COMPUTATION-REF), см. 7.4.2 |
| Дополнительная информация | Здесь дается описание основного критерия обнаружения симптомов отказа. Желательно давать формальное описание с использованием подэлемента ABSTRACT-SYNTAX. Если сложность критерия обнаружения отказа превышает определенный предел, описание также может быть предоставлено в форме словесного описания с использованием подэлемента EXPLANATION. Решение о выборе между формальным и словесным описанием должно приниматься в каждом конкретном случае |
7.6.11.5 Элемент ENABLE-CONDITIONS
В элементе ENABLE-CONDITIONS приводится описание условий физического разрешения (или условий испытания) для каждого элемента FAULT-DETECTION-CRITERIA.
При структурировании описания должны быть приняты во внимание соответствующие определения (см. [6], [7]) и ABSTRACT-SYNTAX (см. 7.4.2). Для описания используются имена внутренних меток блока управления либо термины, указанные в [1]. В таблице 18 определен элемент ENABLE-CONDITIONS.
Определение элемента ENABLE-CONDITIONS:
- каждое условие, которое должно быть выполнено как предварительное условие (один раз или во время полного вычисления критерия обнаружения отказа), по которому может быть вычислен критерий обнаружения отказа, является разрешающим условием (или условием проверки);
- элементарное разрешающее условие обычно может быть представлено в виде: «Метка <простой оператор сравнения> пороговое значение»;
| Ссылка на сводную таблицу БД | Вторичные параметры/разрешающие условия | ||
| Формат | Реализуется как ссылка на вычисление (COMPUTATION-REF), см. 7.4.2 | ||
| Дополнительная информация | Ниже описаны условия, которые должны быть выполнены, чтобы сделать возможным вычисление критерия обнаружения отказа. Следующие условия имеют те же эффекты, что и разрешающие условия, однако они должны быть перечислены в отдельных элементах, поскольку они используются для контроля и фильтрации при последующей обработке документа. | ||
| Элемент | Калибровка | Эффекты | |
| CENTRAL-CALIBRATION-INFORMATION (см. 7.6.12) | Централизованная | Функция мониторинга активна. Управление кодом отказа ингибировано | |
| DISABLE-FULLY (см. 7.6.11.14) | Децентрализованная | Функция мониторинга неактивна | |
| DISABLE-REPORT-ONLY (см. 7.6.11.13) | Децентрализованная | Функция мониторинга активна. Управление кодом отказа ингибировано | |
| Условия запуска, которые активируются с использованием последовательного управления (между функциями двигателя и контроля), должны быть документированы исключительно в элементе EXCLUSION (см. 7.6.13.2) | |||
7.6.11.6 Отладочная информация для обнаружения отказов
Краткое описание процесса подтверждения с учетом примененных «параметров программы». Применяемые «параметры программы» отображаются с помощью процесса ссылки, для которого используется значение, метка или метка с текстовым описанием (см. рисунок 10).
7.6.11.7 Элемент FAULT-DEBOUNCE
Время подтверждения является периодом времени между моментом обнаружения отказа и временем, когда данные об отказе сохраняются в FCM. Оно относится к неисправному компоненту.
- элемент относится к нейтральной системе, т.е. в предшествующие ездовые циклы не было произведено никаких изменений (ни положительных, ни отрицательных) до того, как был установлен дефектный компонент, подлежащий мониторингу. Кроме того, дефектный компонент, подлежащий мониторингу, создает определенное (не меньше и не больше) значение отказа, достаточно большое для того, чтобы система мониторинга смогла обнаружить отказ.
В таблице 19 определен элемент FAULT-DEBOUNCE.
Пример — Подтверждение на основе времени, подтверждение на основе инцидентов и т.д.
ИТС будет нести ответственность за упрощение омологационных документов. Для этого описание метода отладки должно использовать только термины, согласованные с официальными лицами по омологации (спецификация в основной сводной таблице из омологации)
На рисунке 10 показан расчет продолжительности мониторинга.
1 — установлен дефектный компонент; 2 — начало мониторинга;
3 — отказ выявлен; 4 — отказ выявлен и подтвержден;
5 — обновление: диагностические сервисы, IUMPR, FCM;
6 — максимальный период времени для сохранения отказа в FCM в соответствии с действующим законодательством в области БД; 7 — ожидание/MIL
Рисунок 10 — Определение продолжительности мониторинга
7.6.11.8 Элемент MON-FREQUENCY
Поставщик предоставляет необработанную информацию в качестве предложения, а ИТС применяет эту информацию, например, для сводных таблиц в соответствии с данными калибровки.
Перечень возможных значений предоставляется в соответствии с приложением B.
В таблице 20 определен элемент MON-FREQUENCY.
Определение элемента MON-FREQUENCY
Определение частоты мониторинга
На функциональном уровне частота мониторинга описывает наиболее частое выполнение диагностической функциональности, например, диагностический монитор, которое поддерживает ПО ЭБУ.
На уровне конкретного приложения частота мониторинга описывает фактическое поведение диагностической функциональности этого приложения. Далее термин «монитор» относится к одному конкретному элементу FAULT-DETECTION.
Для оценки частоты мониторинга принимаются во внимание все предпосылки, особенно значения, рассчитанные в других функциях, которые используются как часть диагностического монитора.
Пример — Диагностический монитор имеет набор параметров, влияющих на частоту мониторинга:
- «количество раз, за которое монитор выполняется в одном DCY»;
- «время задержки монитора после результата мониторинга».
С двумя данными параметрами диагностический монитор может быть настроен на любой мониторинг от непрерывного до однократного.
Непрерывный мониторинг (Continuous)
«Количество раз, за которое монитор выполняется в одном DCY» = FF (бесконечность),
«Время задержки монитора после результата мониторинга» = 0.
«Количество раз, за которое монитор выполняется в одном DCY» = 1,
«Время задержки монитора после результата мониторинга» = FF (бесконечно).
Один раз за срок службы ЭБУ (Once per ECU lifetime)
Обычно монитор выполняется единожды за срок службы ЭБУ. Это может быть проверка во время изготовления ЭБУ или во время изготовления ТС.
Один раз за ездовой цикл (Once per driving cycle)
Независимо от того, сколько раз разрешающие условия монитора выполняются во время DCY, монитор запускается только один раз и сообщает решение об успешном прохождении теста или отказе, сохраняя в FCM код отказа только один раз.
На рисунке 11 показано, как обрабатывается цикл мониторинга, если он выполняется один раз.
Рисунок 11 — Определение мониторинга за один ездовой цикл
Непрерывный мониторинг (Continuous)
Каждый раз, когда выполняются разрешающие условия монитора, немедленно выполняется диагностический монитор.
По истечении времени, необходимого для выполнения диагностического монитора и передачи отчета в FCM, монитор выполняется вновь.
На рисунке 12 показано, как обрабатывается цикл мониторинга при непрерывном мониторинге.
Диагностический монитор выполняется более одного раза в DCY.
Каждый раз, когда выполняются разрешающие условия, монитор принимает, как минимум, одно решение об отказе или не отказе, а не работает непрерывно.
На рисунке 13 показано, как обрабатывается цикл мониторинга, если применяется множественный мониторинг.
7.6.11.9 Элемент OK-DETECTION-CRITERIA
Данный элемент предоставляет описание алгоритма обнаружения исправного состояния, ссылаясь на элемент COMPUTATION (см. 7.4.2).
Определение элемента OK-DETECTION-CRITERIA:
- OK-DETECTION-CRITERIA — это критерий, который определяет, исчез отказ или нет (критерий исправного состояния);
- данное решение может быть предварительным, т.е. может быть необходима последующая подтверждающая фаза для проведения различия между фактическим устранением отказа и неправильным обнаружением. Эта подтверждающая фаза обычно называется «подтверждение»;
- каждое условие, которое должно быть выполнено как предварительное условие для принятия решения, не относится к OK-DETECTION-CRITERIA. Это разрешающие (или тестовые) условия для устранения отказов.
В таблице 21 определен элемент OK-DETECTION-CRITERIA.
Определение элемента OK-DETECTION-CRITERIA
| Ссылка на сводную таблицу БД | Отсутствует |
|---|---|
| Формат | Реализуется как ссылка на вычисление (COMPUTATION-REF), см. 7.4.2 |
| Дополнительная информация | Здесь указывается описание основного критерия исчезновения симптома отказа. Описание должно предоставляться предпочтительно формально с использованием субэлемента ABSTRACT-SYNTAX. Если сложность критерия обнаружения отказа превышает определенный предел, описание также может быть предоставлено в форме словесного описания с использованием подэлемента EXPLANATION. Решение о выборе формального либо словесного описания должно приниматься в каждом конкретном случае |
7.6.11.10 Элемент OK-ENABLE-CONDITIONS
Данный элемент применяют при описании условий физического включения/проверки исчезновения отказа.
Данный элемент должен использоваться только в том случае, если диагностический монитор асимметричен относительно разрешающих условий (т.е. если разрешающие условия для обнаружения восстановления функциональности отличаются от разрешающих условий для обнаружения отказа).
При составлении описания должны быть приняты во внимание определения из [6] и [7] и ABSTRACT-SYNTAX (см. 7.4.2). Для описания используются имена внутренних меток ЭБУ. В противном случае для определения разрешающего условия должны использоваться главным образом термины, указанные в [1].
Ниже приведено определение разрешающих условий для восстановления функциональности.
Каждое условие, которое должно быть выполнено как предварительное условие (один раз или во время полного вычисления критерия обнаружения восстановления функциональности), по которому может быть вычислен критерий обнаружения восстановления функциональности, является разрешающим условием или условием проверки:
- элементарное разрешающее условие обычно может быть представлено в форме: «Метка <простой условный оператор> порог»;
- отдельные элементарные разрешающие условия могут быть объединены другими операторами, такими как «И», «ИЛИ» и т.д.
В таблице 22 определен элемент OK-ENABLE-DETECTION.
| Ссылка на сводную таблицу БД | Отсутствует |
|---|---|
| Формат | Реализуется как ссылка на вычисление (COMPUTATION-REF), см. 7.4.2 |
| Дополнительная информация | Здесь описаны условия, которые должны быть выполнены для разрешения вычисления критерия обнаружения восстановления функциональности |
7.6.11.11 Элемент OK-DEBOUNCE
Данный элемент используют для краткого описания подтверждения при определении исправного состояния с учетом примененных «параметров программы». Применяемые «параметры программы» отображаются с помощью процесса ссылки, для которого используется значение, метка или метка с текстовым описанием (см. рисунок 10).
В таблице 23 определен элемент OK-DEBOUNCE.
| Ссылка на сводную таблицу БД | Отсутствует |
|---|---|
| Формат | Реализуется как ссылка на вычисление (COMPUTATION-REF) |
7.6.11.12 Ссылка на законодательство в области БД
7.6.11.12.1 Общие положения
Данный элемент необходим для обозначения симптомов отказов, связанных с БД, и для других симптомов будет опущен. Этот элемент содержит ссылку на ту часть законодательства, которая инициировала введение или изменение симптома отказа и будет предоставлена поставщиком.
7.6.11.12.2 Элемент LEGISLATION
Ссылка на элемент LEGISLATION должна быть представлена в виде текстового поля с символами ASCII. Содержание текстового поля должно быть номером раздела регламента и его детализацией.
Для данного элемента не ожидается никаких обновлений в течение срока службы ПО, однако в случае введения новых функций, которые приведут к другому названию симптома отказа, следует указать новый раздел LEGISLATION. В таблице 24 определена ссылка на LEGISLATION в области БД.
| Ссылка на сводную таблицу БД | MCL |
|---|---|
| Формат | Текстовое поле с символами ASCII Дополнительно, необязательный XML-элемент получает имя MCL-STRATEGY |
| Дополнительная информация | Данная информация является первым шагом к созданию списка MONITORING REQUIREMENTS, который иллюстрирует связь между компонентом, разделом законодательства и кодом (см. [3]). Присвоение «Названия симптома отказа» коду отказа выполняется ИТС с использованием данных |
7.6.11.12.3 Элемент MCL-STRATEGY
Данная информация необходима для всех комплексных компонентов, имеющих отношение к БД, и содержит общее описание элемента FAULT-DETECTION-STRATEGY для элемента FAULT-SYMPTOM. Используемая терминология указана в реестре выбора (в соответствии с приложением B). В таблице 25 определен элемент MCL-STRATEGY.
| Ссылка на сводную таблицу БД | MCL |
|---|---|
| Формат | Текстовое поле с символами ASCII |
| SELECTION-LIST-NAME | MCL_STRATEGY |
7.6.11.13 Элемент DISABLE-REPORT-ONLY
Неактивные условия следует отличать от условий физического включения, поскольку неактивные условия:
- не могут измениться во время работы ЭБУ (они обычно фиксируются процессом инженерной калибровки);
- будут использоваться для управления дальнейшей обработкой документации.
Данный элемент предоставляет описание условий, определенных внутри функции, которые должны быть выполнены, чтобы обнаружение отказа было деактивировано.
В элементе DISABLE-REPORT-ONLY должны быть описаны неактивные условия, которые деактивируют отчеты об отказах только в FCM, тогда как расчет диагностического алгоритма не деактивируется.
Описание реализуется посредством ссылки на COMPUTATION (см. 7.4.2). В таблице 26 определен элемент DISABLE-REPORT-ONLY.
Определение элемента DISABLE-REPORT-ONLY
| Ссылка на сводную таблицу БД | Неактивные условия не должны появляться в сводной таблице БД |
|---|---|
| Формат | Реализуется как ссылка на вычисление (COMPUTATION-REF). Элемент может содержать имя метки калибровки (абстрактный синтаксис) либо фактическое значение, введенное в виде десятичного значения |
| Дополнительная информация | Здесь вводится, какие условия должны быть выполнены, чтобы деактивировать отчет об отказе. Данный пункт имеет различия с 7.6.12 (CENTRAL-CALIBRATION-INFO). В обоих случаях вывод отказа подавляется, однако в этом случае сама функция, а не центральная метка, подавляет отчет об отказе |
7.6.11.14 Элемент DISABLE-FULLY
Неактивные условия следует отличать от условий физического включения, поскольку неактивные условия:
- не могут измениться во время работы ЭБУ (они обычно фиксируются процессом технической калибровки);
- будут использоваться для управления дальнейшей обработкой документации.
Данный элемент предоставляет описание внутренних условий функции, которые должны быть выполнены, чтобы обнаружение отказа было деактивировано.
В элементе DISABLE-FULLY должны быть описаны неактивные условия, которые деактивируют вычисление диагностического алгоритма, чтобы в FCM не сохранялось сообщение об отказе.
Описание реализуется посредством ссылки на COMPUTATION (см. 7.4.2). В таблице 27 определен элемент DISABLE-FULLY.
7.6.11.15 Информация о БД-сервисе 0616
Для разрешения повторного использования этой информации указываются один или несколько конкретных элементов в списке БД-сервиса службы 0616. Требования к запросу результатов бортового мониторинга для конкретных контролируемых систем приведены в [8]. Подробное описание информации о БД-сервисе 0616 см. в 7.8. Данная информация будет указана только для симптомов отказа, относящихся к БД-сервису 0616.
7.6.11.16 Элемент GENERIC-TYPE
Данный элемент содержит информацию, к какому типу диагностики относится симптом отказа.
Поддерживаются следующие значения:
В таблице 28 определен элемент GENERIC-TYPE.
Определение элемента GENERIC-TYPE
| Ссылка на сводную таблицу БД | Отсутствует |
|---|---|
| Формат | Текстовое поле с символами ASCII |
| Атрибут | Вариант использования |
| SELECTION-LIST-NAME | GENERIC_TYPE |
Описание поддерживаемых стандартных значений:
- COMMUNICATION: симптом отказа обнаруживает ошибку связи между двумя ЭБУ или между одним ЭБУ и интеллектуальным компонентом;
- ELECTRICAL: симптом отказа обнаруживает электрические ошибки, которые отслеживаются постоянно или непостоянно; более подробная классификация частоты мониторинга может быть создана с использованием уже существующего элемента MON-FREQUENCY;
- OTHER DIAGNOSIS: симптом отказа обнаруживает ошибки, которые не являются электрическими или коммуникационными (ошибками связи).
7.6.12 Элемент CENTRAL-CALIBRATION-INFOS
Данный элемент обеспечивает центральные метки калибровки, которые влияют на поведение ПО, связанного с симптомом отказа, и, следовательно, на поведение самого симптома отказа.
Центральное средство предоставляется центральным функционалом сервиса (например, диспетчером симптомов отказов) для всех симптомов отказа программы, в отличие от меток калибровки, локально определенных в конкретных функциях ПО.
Данные метки центральной калибровки, хотя они и указывают разрешающее условие с логической точки зрения, не должны указываться как часть общих разрешающих условий (см. 7.6.11.5), поскольку они не представляют условия физического включения (т.е. их значение не изменится во время работы ЭБУ) и будут использоваться для управления дальнейшей обработкой документации.
Элемент COMPUTATION-REF содержит информацию метки, т.е. имя метки калибровки, тогда как элемент INFO-TYPE содержит информацию о типе информации.
Поскольку описанные калибровочные метки будут в основном зависеть от поставщика, значения INFO-TYPE также будут зависеть от поставщика.
Если поставщик использует более одной калибровочной этикетки, все они должны быть указаны.
В таблице 29 определен элемент CENTRAL-CALIBRATION-INFO.
Определение элемента CENTRAL-CALIBRATION-INFO
7.6.13 Информация элемента INHIBITIONS
7.6.13.1 Элемент INHIBITIONS по симптомам
Элемент INHIBITIONS по симптомам содержит список симптомов (FAULT-SYMPTOM-REFS), которые ингибируют вычисление описанного в настоящее время симптома отказа (жестко закодировано), или предоставляет список FID (FID-REFS), причем каждый FID предоставляет список ингибирующих симптомов отказов (FAULT-SYMPTOM-REFS) или ингибирующих вспомогательных объектов (AUXILIARY-OBJECT-REFS).
В приложении D содержится дополнительная информация и определен список FID для валидации.
В таблице 30 определен список FID для валидации.
| Ссылка на сводную таблицу БД | Вторичный параметр |
|---|---|
| Формат | Содержит набор ссылок на идентификатор функции (FID) с дочерним элементом FID-TYPE, установленным для валидации |
| Дополнительная информация | Все калибровочные назначения (см. рисунок D.2, приложение D) должны быть перечислены для всех валидирующих FID и ингибирующих FID, на которые ссылаются элементы INHIBITION. Это касается, например, симптомов, качества сигналов, вспомогательных событий и т.п. Для осуществления полной оценки распределений приложений необходимо указать статус подтверждения, действительный для указанных выше отдельных распределений, чтобы принять во внимание FID. Пример - Пределы (например, Def50_Deb100, Tested, ...) Качество сигнала (1... 15) Маски (ERR, PND, REC, ...) |
Элемент INHIBITIONS по симптомам предоставляет список FID (FID-REFS), причем каждый FID предоставляет список ингибирующих симптомов отказов или через COMPUTATION-REF калибровочные метки, которые также содержат список ингибирующих симптомов отказов. В таблице 31 определен перечень INHIBITIONS BY-SYMPTOM через FID.
| Ссылка на сводную таблицу БД | Диаграмма запрещения |
|---|---|
| Формат | Реализуется как набор ссылок на идентификатор функции (INHIBITIONS/BY-SYMPTOM/FID-REFS/FID-REF), каждая из которых ссылается на набор ингибирующих симптомов отказа (FIDS/FID/FAULT-SYMPTOM-REFS/FAULT-SYMPTOM_REF) или ингибирующие вспомогательные объекты (FIDS/FID/AUXILIARY-OBJECT-REFS/AUXILIARY-OBJECT-REF) |
| Дополнительная информация | Все распределения калибровки (см. рисунок D.2, приложение D) должны быть перечислены для всех идентификаторов проверки и ингибирующих FID, на которые ссылается элемент INHIBITIONS. Это относится, например, к симптомам, качеству сигналов, вспомогательным событиям и т.п. Для осуществления полной оценки распределений калибровки необходимо перечислить статусы подтверждения, действительные для указанных выше отдельных назначений, чтобы принять во внимание FID. Пример - Пределы (например, Def50_Deb100, Протестировано, ...) Сигнальные качества (1... 15) Маски (ERR, PND, REC, ...) Эта дополнительная информация не обязательно должна предоставляться всем ИТС |
Ниже приведено описание симптомов отказа, которые будут ингибировать описанный симптом отказа непосредственно в ПО.
В таблице 32 определено описание ингибирующих симптомов отказа (жестко закодировано).
| Ссылка на сводную таблицу БД | Диаграмма запрещения |
|---|---|
| Формат | Список имен симптомов отказов, используемых в контейнере, содержащем элемент |
7.6.13.2 Элемент INHIBITIONS по функциям
Элемент INHIBITIONS по функциональности содержит информацию, касающуюся временного запрещения вычисления рассматриваемого симптома отказа с помощью элемента EXCLUSION, что означает продолжающееся выполнение из-за другой функциональности. Элемент EXCLUSION может быть описан поставщиком как:
- свободный текст для обозначения запрещающих функций;
- ссылка на одну или несколько меток калибровки, содержащих один или несколько запрещающих FID.
ИТС может подготовить элемент EXCLUSION для использования в сводной таблице в официальной форме.
Для реализации этих требований данный элемент предоставляет элемент EXCLUSION путем ссылки на элементы COMPUTATION (см. 7.4.2).
Некоторые диагностические функции не могут выполняться одновременно с другими функциями, например, адаптация рабочей смеси и вентиляция топливного бака. Это подавление следует рассматривать так же, как и состояние ингибирования, и соответственно планировать. Должны быть введены все названия симптомов и/или функций, которые находятся в прямом соответствии с рассматриваемым симптомом. Если исключения могут быть определены через приложение, должны быть указаны соответствующие ярлыки приложения.
В таблице 33 определен элемент EXCLUSIONS.
Определение элемента EXCLUSIONS
| Ссылка на сводную таблицу БД | Условия разрешения |
|---|---|
| Формат | Текстовое поле с символами ASCII |
| Элемент 1 | Один или более ярлыков приложения |
| Элемент 2 | Область описания |
7.6.14 Элемент SUBSTITUTION-FUNCTION
Описание необязательных внутренних функций, которые активируются после сохранения симптома отказа в FCM, должно быть представлено в текстовом формате XHTML. Активация замещающей функции осуществляется через жестко закодированную связь между симптомом и замещающей функцией.
Примечание — В данном пункте описаны только те меры, которые активируются функцией/модулем и вызывают запись симптома отказа в FCM (т.е. внутреннюю функцию).
В таблице 34 определено описание SUBSTITUTION-FUNCTION (жестко закодировано).
| Ссылка на сводную таблицу БД | Отсутствует |
|---|---|
| Формат | Описание в формате XHTML, воспринимаемом человеком |
7.6.15 Элемент PROTECTIVE-FUNCTION
Описание необязательных внутренних функций, которые активируются до того, как симптом отказа будет сохранен в FCM, должно быть представлено в текстовом формате XHTML.
Примечание — Функция активации PROTECTIVE-FUNCTION не калибруется, а жестко запрограммирована в ПО. Такое поведение обычно нежелательно, но для защиты людей и технического оборудования его не всегда можно избежать по техническим причинам.
В таблице 35 определен элемент PROTECTIVE-FUNCTION.
Определение элемента PROTECTIVE-FUNCTION
| Ссылка на сводную таблицу БД | Отсутствует |
|---|---|
| Формат | Описание в формате XHTML, воспринимаемом человеком |
7.6.16 Элемент SIMULATION-METHOD
Данный элемент обеспечивает приблизительную классификацию метода моделирования для запуска симптома отказа, связанного с БД.
В таблице 36 определен элемент SIMULATION-METHOD.
Поддерживаемые стандартные значения и их семантика (с примерами):
- MODIFIED COMPONENT: для компонента была разработана специальная электрическая или механическая манипуляция, которая должна иметь те же эффекты, что и реальный отказ.
Эффективность сажевого фильтра: механическое разрушение.
Эффективность бензинового катализатора: старение с использованием печи;
- EXTERNAL SIGNAL SIMULATION BOX: для запуска симптома отказа необходимо моделирование входов системы (сигнал датчиков).
Датчик O2 с низким быстродействием.
- EXTERNAL ACTUATOR DRIVER BOX: чтобы вызвать симптом отказа, требуется имитация выходов (положение привода) через приспособление, искажающее выходной сигнал ЭБУ.
Заклинившая в закрытом положении заслонка рециркуляции выхлопных газов.
Генерация пропусков зажигания через катушку зажигания;
- SOFTWARE CONTROL STRATEGY: для вызова симптома отказа была разработана специальная стратегия управления ПО по моделированию среды. Стратегия должна быть активирована с помощью запроса от внешнего инструмента, приспособление для EXTERNAL ACTUATOR DRIVER BOX не требуется.
Пропуск зажигания через запрос от инструмента.
Датчик O2 с низким быстродействием;
- NOT FEASIBLE при омологации: невозможно продемонстрировать отказ, связанный с симптомом отказа (например, если существует риск серьезного повреждения ТС).
Электрический сбой датчика атмосферного давления (когда датчик давления находится внутри ЭБУ и недоступен);
7.6.17 Элемент ##other-Information (для симптомов)
Цель данного механизма — добавить любое содержание XML с пространством имен, отличным от пространства имен «no-name». Например, ИТС могут перечислить дополнительную собственную информацию о конкретных симптомах (вариант использования 2.2, см. 5.3).
В таблице 37 определена стыковочная точка для собственного расширения ИТС.
Стыковочная точка для собственного расширения ИТС
| Ссылка на сводную таблицу БД | Отсутствует |
|---|---|
| Формат | XML |
7.7 Элемент FAULT-SYMPTOM-3RD-PARTYS
Для симптома отказа 3-й стороны доступны следующие элементы:
- SHORT-NAME: название симптома отказа, используемое компанией, предоставляющей документ FXD;
- THIRD-PARTY/COMPANY-DATA-REF: ссылка на компанию, которая изначально предоставляет сторонние функции по обнаружению отказов;
- THIRD-PARTY/FAULT-SYMPTOM-3RD-PARTY-SHORT-NAME: имя симптома отказа, определенное компанией, которая изначально предоставляет сторонние функции по обнаружению отказов.
В таблице 38 определен элемент FAULT-SYMPTOM-3RD-PARTY.
| Ссылка на сводную таблицу БД | Отсутствует |
|---|---|
| Формат | Текстовое поле с символами ASCII |
| - | Текстовое описание в XHTML-формате для данной функции |
7.8 Элемент SERVICE-06-IDS
Служба БД 06 «Запрос результатов бортового мониторинга для конкретных контролируемых систем» определена в [2] или [8].
Данный пункт содержит список всех идентификаторов службы БД 06, на которые ссылаются симптомы отказов. Информация, относящаяся к службе 06, описывается подэлементами SERVICE-06-ID. Каждый результат теста выводится службой БД 06 с OBDMID (Monitor-ID), TID (Test-ID) и USID (Unit и Scaling ID):
- OBDMID используется всесторонне для всех ИТС и указывает на соответствующий компонент;
- для каждого OBDMID может быть назначено несколько TID. Эти TID соответствуют отдельным симптомам отказа, и каждый из них содержит тестовое значение (метка измерения), нижнее и верхнее предельные значения теста (метка приложения или метка приложения с индексацией);
- USID используется для указания единицы измерения и масштабирования контролируемого значения;
- в случае, если требуется специальный алгоритм для доступа к данным (например, для предоставления индекса в дополнение к метке), необходимо указать способ получения правильной информации между производителем и поставщиком ТС.
В таблице 39 определен вывод результатов тестов через службу внешнего тестового оборудования 06 (например, 21 для мониторинга катализатора).
В таблице 40 определен вывод результатов тестов через службу БД 0616 (TID).
Определение TID службы БД 0616
В таблице 41 определен вывод результатов испытаний через службу внешнего испытательного оборудования 0616 (Unit and Scaling ID).
Определение службы БД 0616 USID
| Ссылка на сводную таблицу БД | Отсутствует |
|---|---|
| Формат | USID вводится в шестнадцатеричной форме (например, 1C16) |
| - | Для каждого TID должен быть указан USID. На один OBDMID может быть несколько TID |
7.9 Элемент FIDS
7.9.1 Основные положения
Данный пункт описывает элементы FXD-схемы, определяющие информацию, специфичную для идентификатора функции.
7.9.2 ID элемента
Ключ описания (на основе симптомов отказа): специфическое для поставщика уникальное имя идентификатора функции, описанное в соответствии с 6.6.
Примечание — Элемент SHORT-NAME идентификатора функции соответствует идентификатору функции файла «a2I».
7.9.3 Элемент FID-TYPE
Существуют три различных типа идентификатора функции с возможными значениями:
- CALCULATION;
- VALIDATION;
- OTHER — для целей, не связанных с симптомами отказов, например, аварийный режим работы АКПП.
При смешивании типов должен использоваться элемент CALCULATION.
7.9.4 Элемент ECU-FUNC
7.9.4.1 Элемент LONG-NAME
Это специфичное для поставщика имя функции ЭБУ, формируемое идентификатором функции в соответствии со спецификацией HDO LONG-NAME.
7.9.4.2 Элемент VERSION
Это версия ECU-FUNC, как указано в элементе «a2I» FUNCTION_VERSION, для функции, в которой сконфигурирован FID.
7.9.5 Элемент FAULT-SYMPTOM-REFS
Содержит симптомы отказа, которые влияют на FID (т.е. действуют как источник ингибирования), и указываются, если необходимо, вместе с определенным MASK-REF.
В таблице 42 определен ссылочный элемент FAULT-SYMPTOM-REFS.
Определение элемента FAULT-SYMPTOM-REFS
| Ссылка на сводную таблицу БД | Таблица запрещения |
|---|---|
| Формат | Перечень симптомов отказа как в файле «a2I» |
7.9.6 Элемент AUXILIARY-OBJECT-REFS
Содержит ссылки на другие элементы (например, уровень качества сигнала), которые влияют на FID (например, действуют как источник ингибирования), если необходимо, вместе с конкретным элементом MASK.
В таблице 43 определен ссылочный элемент AUXILIARY-OBJECT-REFS.
| Ссылка на сводную таблицу БД | Таблица запрещения |
|---|---|
| Формат | Перечень уровней качества сигнала, как в файле «a2I» |
7.9.7 Элемент EXPLANATION
В данном элементе каждый FID описывается более подробно (DESC), включая замещающие реакции. Кроме того, он может включать список элементов ЭБУ (например, параметров калибровки), относящихся к этому FID (DATA-DECLARATION-REFS).
В таблице 44 определен элемент FID EXPLANATION.
Определение элемента EXPLANATION
7.10 Элемент AUXILIARY-OBJECTS
Вспомогательные объекты — это объекты, которые можно использовать для запрещения вычисления идентификатора функции (FID) так же, как используются симптомы отказов. Следовательно, их использование в конфигурации/определении идентификатора функции идентично использованию симптома отказа.
7.11 Элемент MASKS
В элементе MASKS должны быть перечислены все маски, на которые ссылаются отдельные подэлементы FAULT-SYMPTOM-REFS каждого FID.
Маски используются для детализации (системных) условий, при которых данный симптом отказа или вспомогательные объекты фактически действуют как источник ингибирования. Таким образом, маска может содержать, например, подробную информацию об уровне дефекта или состоянии отладки.
7.12 Элемент TEXT-MAPPINGS
Отображение текста предоставляет возможность определить представление текста, например, онлайн-переменную для псевдонима. Этот элемент может использоваться ИТС для замены текстов, которые определены в файле FXD, внутренними именами ИТС или именами, требуемыми законодателем. Отображение 1-в-1 определяется элементом TEXT-MAP, его дочерними элементами TI и его псевдонимом TEXT.
7.13 Любая иная информация (для контейнера)
В конце симптома отказа допустимо добавлять любое содержание XML с пространством имен, отличающимся от пространства без имени. Это может быть полезно, если в FXD-файле, кроме информации, определенной моделью FXD, должна передаваться и другая информация.
ЦИФРОВОЕ ПРИЛОЖЕНИЕ FXD XML-СХЕМЫ
XML-схема FXD доступна в виде электронного приложения к настоящему стандарту.
Для удобства пользования стандартом следующие пункты включают эти документы.
A.1.2 FXD-Schema V2.0.0 xml.xsd
<xs:schema targetNamespace=«http://www.w3.org/XML/1998/namespace»xmlns:xs=«http:// www.w3.org/2001/XMLSchema„xml:lang=“en»>
*<xs:annotation>*
*<xs:documentation>*
*See http://www.w3.org/XML/1998/namespace.html and http://www.w3.org/TR/REC-xml for*
*information about this namespace.*
*This schema document describes the XML namespace, in a form suitable for import by other*
*schema documents.*
*Note that local names in this namespace are intended to be defined only by the World Wide Web*
*Consortium or its subgroups. The following names are currently defined in this namespace and should not*
*be used with conflicting semantics by any Working Group, specification, or document instance:*
*base (as an attribute name): denotes an attribute whose value provides a URI to be used as the base for*
*interpreting any relative URIs in the scope of the element on which it appears; its value is inherited.*
*This name is reserved by virtue of its definition in the XML Base specification.*
*lang (as an attribute name): denotes an attribute whose value is a language code for the natural language*
*of the content of any element; its value is inherited. This name is reserved by virtue of its definition*
*in the XML specification.*
*space (as an attribute name): denotes an attribute whose value is a keyword indicating what whitespace*
*processing discipline is intended for the content of the element; its value is inherited. This name is*
*reserved by virtue of its definition in the XML specification.*
*Father (in any context at all): denotes Jon Bosak, the chair of the original XML Working Group. This name*
*is reserved by the following decision of the W3C XML Plenary and XML Coordination groups:*
*In appreciation for his vision, leadership and dedication the W3C XML Plenary on this*
*10th day of February, 2000 reserves for Jon Bosak in perpetuity the XML name*
*xml:Father*
*</xs:documentation>*
*</xs:annotation>*
*<xs:annotation>*
xs:documentationThis schema defines attributes and an attribute group suitable for use by schemas wishing to allow xml:base, xml:lang or xml:space attributes on elements they define.
*To enable this, such a schema must import this schema for the XML namespace, e.g. as follows: &It;*
*schema ...>*
*...*
*&It;import namespace="http://www.w3.org/XML/1998/namespace"*
*schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>*
*Subsequently, qualified reference to any of the attributes or the group defined below will have the desired*
*effect, e.g.*
*&It;type ...>*
*...*
*&It;attributeGroup ref="xml:specialAttrs"/>*
*will define a type which will schema-validate an instance element with any of those attributes</*
*xs:documentation>*
*</xs:annotation>*
*<xs:annotation>*
xs:documentationIn keeping with the XML Schema WG's standard versioning policy, this schema document will persist at http://www.w3.org/2001/03/xml.xsd.
*At the date of issue it can also be found at*
*http://www.w3.org/2001/xml.xsd.*
*The schema document at that URI may however change in the future,*
*in order to remain compatible with the latest version of XML Schema*
*itself. In other words, if the XML Schema namespace changes, the version*
*of this document at*
*http://www.w3.org/2001/xml.xsd will change*
*accordingly; the version at*
*http://www.w3.org/2001/03/xml.xsd will not change.*
</xs:documentation> </xs:annotation>
*<xs:attribute name="lang" type="xs:language">*
*<xs:annotation>*
*<xs:documentation>In due course, we should install the relevant ISO 2-and*
*3-letter codes as the enumerated possible values ...</xs:documentation>*
*</xs:annotation>*
*</xs:attribute>*
*<xs:attribute name="space" default="preserve">*
*<xs:simpleType>*
*<xs:restriction base="xs:NCName">*
*<xs:enumeration value="default"/>*
*<xs:enumeration value="preserve"/>*
*</xs:restriction>*
*</xs:simpleType>*
*</xs:attribute>*
*<xs:attribute name="base" type="xs:anyURI">*
*<xs:annotation>*
*<xs:documentation> По адресу: http://www.w3.org/TR/xmlbase/ см. информацию об этом атрибуте.*
</xs:documentation> </xs:annotation> </xs:attribute> <xs:attributeGroup name=«specialAttrs»> <xs:attribute ref=«xml:base»/> <xs:attribute ref=«xml:lang»/>
*<xs:attribute ref="xml:space"/>*
*</xs:attributeGroup>*
*</xs:schema>*
A.1.3 FXD-Schema V.2.0.0 fxd.xsd
*<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"*
*elementFormDefault="qualified" attributeFormDefault="unqualified">*
*<xs:import namespace="http://www.w3.org/XML/1998/namespace"*
*schemaLocation="xml.xsd"/>*
*<xs:include schemaLocation="fxd-xhtml.xsd"/>*
*<xs:complexType name="ABSTRACT-SYNTAX">*
*<xs:sequence>*
*<xs:group ref=" EXPR"/>*
*</xs:sequence>*
*</xs:complexType>*
*<xs:complexType name="ADDRESS">*
*<xs:simpleContent>*
*<xs:extension base= "xs:string"/>*
*</xs:simpleContent>*
*</xs:complexType>*
*<xs:complexType name="ADMIN-DATA">*
*<xs:sequence>*
*<xs:element name="COMPANY-DATA-REF" type="LINK"/>*
*<xs:element name="ECU-FAMILY" type="ECU-FAMILY"/>*
*<xs:element name= "PROJECT" type= "PROJECT"/>*
*<xs:element name= "RESOURCES" type= "RESOURCES"/>*
*<xs:element name= "DOC-REVISIONS" type= "DOC-REVISIONS"/>*
*</xs:sequence>*
*</xs:complexType>*
*<xs:complexType name="ASSIGNABLE" abstract="true">*
*<xs:sequence>*
*<xs:element name="COMPUTATION-REF" type="LINK"/>*
*</xs:sequence>*
*</xs:complexType>*
*<xs:complexType name="AUXILIARY-OBJECT">*
*<xs:sequence>*
*<xs:group ref=" ELEMENT-ID"/>*
*</xs:sequence>*
*<xs:attributeGroup ref="ID-ATTRIBUTE"/>*
*</xs:complexType>*
*<xs:complexType name="AUXILIARY-OBJECT-REFS">*
*<xs:sequence>*
*<xs:element name="AUXILIARY-OBJECT-REF" type="MASKED-LINK"*
maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«AUXILIARY-OBJECTS»> xs:sequence <xs:element name=«AUXILIARY-OBJECT» type=«AUXILIARY-OBJECT» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«BIT-FIELD»> xs:sequence <xs:element name=«LONG-NAME» type=«LONG-NAME»/> <xs:element name=«BIT-MASK» type=«xs:positiveInteger»/> <xs:element name=«BIT-FIELD-COMPUTATION» type=«BIT-FIELD-»
COMPUTATION«/>
</xs:sequence>»
</xs:complexType><br>
<xs:complexType name="BIT-FIELD-COMPUTATION"><br>
<xs:complexContent>
<xs:extension base="ASSIGNABLE"/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="BIT-FIELD-VARIABLE">
<xs:sequence>
<xs:element name="BIT-FIELD" type"BIT-FIELD" minOccurs="1"
maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType>
<xs:complexType name="BY-FUNCTION"><br>
<xs:sequence><br>
<xs:element name= "EXCLUSIONS" type= "EXCLUSIONS" minOccurs="0"/><br>
</xs:sequence><br>
</xs:complexType><br>
<xs:complexType name="BY-SYMPTOM">
<xs:sequence>
<xs:element name="FAULT-SYMPTOM-REFS" type="FAULT-SYMPTOM-REFS"
minOccurs=«0»/> <xs:element name=«AUXILIARY-OBJECT-REFS» type=«AUXILIARY-OBJECT- REFS» minOccurs=«0»/> <xs:element name= «FID-REFS» type= «FID-REFS» minOccurs=«0»/>
</xs:sequence><br>
</xs:complexType><br>
<xs:complexType name="CENTRAL-CALIBRATION-INFO">
<xs:complexContent><br>
<xs:extension base="ASSIGNABLE"><br>
<xs:sequence>
<xs:element name="INFO-TYPE" type="INFO-TYPE"/>
</xs:sequence>
</xs:extension>
</xs:complexContent><br>
</xs:complexType><br>
<xs:complexType name="CENTRAL-CALIBRATION-INFOS">
<xs:sequence>
<xs:element name="CENTRAL-CALIBRATION-INFO" type="CENTRAL-CALIBRATION-
INFO«maxOccurs=»unbounded«/> </xs:sequence> </xs:complexType> <xs:complexType name=»CITY«> xs:simpleContent <xs:extension base= „xs:string“/> </xs:simpleContent> </xs:complexType> <xs:complexType name=»COMPANY-DATA«> xs:sequence <xs:group ref=» ELEMENT-ID«/> <xs:element name=»TEAM-MEMBERS» type=«TEAM-MEMBERS» minOccurs=«0»/> </xs:sequence> <xs:attributeGroup ref=«ID-ATTRIBUTE»/> </xs:complexType> <xs:complexType name=«COMPANY-DATAS»> xs:sequence <xs:element name=«COMPANY-DATA» type=«COMPANY-DATA» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name= «COMPU-CONST»> xs:complexContent <xs:extension base=«OPERAND»> xs:sequence <xs:group ref=«EVALUABLE-ENTITY»/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name=«COMPU-CONST» type=«COMPU-CONST» substitutionGroup=«OPERAND»/> <xs:complexType name=«COMPU-VAR»> xs:complexContent <xs:extension base=«OPERAND»> xs:sequence <xs:element name=«DATA-DECLARATION-REF» type=«LINK»/> </xs:sequence> </xs:extension>
</xs:complexContent><br>
</xs:complexType><br>
<xs:element name="COMPU-VAR" type="COMPU-VAR" substitutionGroup="OPERAND"/>
<xs:complexType name="COMPUTATION"><br>
<xs:sequence><br>
<xs:group ref=" ELEMENT-ID"/>
<xs:choice>
<xs:element name="EXPLANATION" type="EXPLANATION"/>
<xs:element name="ABSTRACT-SYNTAX" type="ABSTRACT-SYNTAX"/>
</xs:choice>
</xs:sequence>
<xs:attributeGroup ref="ID-ATTRIBUTE"/>
<xs:attribute ref=" xml:lang"/>
</xs:complexType>
<xs:complexType name="COMPUTATIONS">
<xs:sequence>
<xs:element name="COMPUTATION" type="COMPUTATION" minOccurs="0"
maxOccurs=«unbounded»/>
</xs:sequence>
</xs:complexType><br>
<xs:complexType name="CONFIGURATION"><br>
<xs:sequence>
<xs:element name="DATA-DECLARATION-REFS" type="DATA-
DECLARATION-REFS«/> </xs:sequence> </xs:complexType> <xs:complexType name= „CUSTOM-CODE“> xs:complexContent <xs:extension base=»FAULT-CODE«> xs:sequence <xs:element name=»CUSTOM-CODE-TYPE» type=«CUSTOM-CODE- TYPE»/>
</xs:sequence><br>
</xs:extension><br>
</xs:complexContent>
</xs:complexType><br>
<xs:simpleType name="CUSTOM-CODE-TYPE"><br>
<xs:restriction base="xs:NMTOKEN"/>
</xs:simpleType>
<xs:complexType name= "CUSTOM-CODES">
<xs:sequence>
<xs:element name= "CUSTOM-CODE" type= "CUSTOM-CODE"<br>
maxOccurs=«unbounded»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«DATA»>
xs:sequence
<xs:element name="DATA-NAME" type="xs:string"/>
<xs:element name="DATA-TYPE" type="DATA-TYPE"/>
<xs:element name="DISPLAY-NAME" type="TEXT" minOccurs="0"/>
**<xs:element name="DATA-VALUE" type="VALUE" minOccurs="0"/>**
**</xs:sequence>**
**</xs:complexType>**
<xs:complexType name="DATA-DECLARATION">
<xs:sequence>
<xs:group ref=" ELEMENT-ID"/>
**<xs:element name="DATA" type="DATA"/>**
**</xs:sequence>**
**<xs:attributeGroup ref="ID-ATTRIBUTE"/>**
</xs:complexType>
<xs:complexType name="DATA-DECLARATION-REFS">
<xs:sequence>
<xs:element name="DATA-DECLARATION-REF" type="LINK"
maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«DATA-DECLARATIONS»> xs:sequence <xs:element name=«DATA-DECLARATION» type=«DATA-DECLARATION» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«DATA-DICTIONARY»> xs:sequence <xs:element name=«DATA-DECLARATIONS» type=«DATA-DECLARATIONS»/>
<xs:element name="COMPUTATIONS" type="COMPUTATIONS"/><br>
<xs:element name= "UNIT-SPEC" type= "UNIT-SPEC"/><br>
</xs:sequence><br>
</xs:complexType>
<xs:simpleType name="DATA-TYPE">
<xs:restriction base="xs:NMTOKEN">
**<xs:enumeration value="CALIBRATED"/>**<br>
**<xs:enumeration value="CALIBRATION-INFO"/>**<br>
**<xs:enumeration value="NON-CALIBRATABLE"/>**
<xs:enumeration value ="ONLINE"/>
<xs:enumeration value="STATE-VALUE"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="DEPARTMENT">
<xs:simpleContent>
<xs:extension base= "xs:string"/>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name= "DESC-EXTENT">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value ="COMPLETE"/>
<xs:enumeration value="PARTIAL"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="DESC-STATE">
<xs:restriction base= "xs:string">
<xs:enumeration value="INITIAL"/>
<xs:enumeration value="DRAFT"/>
<xs:enumeration value="RELEASED"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name= "DESCRIPTION">
<xs:sequence>
<xs:group ref="block" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="EXTERNAL-DOCS" type="EXTERNAL-DOCS"
minOccurs=«0»/> </xs:sequence> <xs:attributeGroup ref=«TI-ATTRIBUTE»/> </xs:complexType> <xs:complexType name=«DISABLE-FULLY»> xs:complexContent <xs:extension base=«ASSIGNABLE»/> </xs:complexContent> </xs:complexType> <xs:complexType name=«DISABLE-REPORT-ONLY»> xs:complexContent <xs:extension base=«ASSIGNABLE»/> </xs:complexContent> </xs:complexType> <xs:complexType name= «DOC-REVISION»> xs:sequence <xs:element name=«REVISION-LABEL» type=«xs:string» minOccurs=«0»/> <xs:element name=«STATE» type=«DOCUMENT-STATE»/> <xs:element name=«DATE» type=«xs:dateTime»/> </xs:sequence> </xs:complexType> <xs:complexType name= «DOC-REVISIONS»> xs:sequence <xs:element name= «DOC-REVISION» type= «DOC-REVISION» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:simpleType name=«DOCUMENT-STATE»> <xs:restriction base= «xs:string»> <xs:enumeration value =«DEVELOPMENT»/> <xs:enumeration value =«SERIES»/> <xs:enumeration value=«RELEASED»/> </xs:restriction> </xs:simpleType> <xs:complexType name=«ECU-FAMILY»> xs:complexContent
<xs:extension base="SELECTABLE"/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name= "ECU-FUNC">
<xs:sequence>
<xs:element name="LONG-NAME" type="LONG-NAME"/>
<xs:element name= "VERSION" type= "xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name= "ECU-FUNCS">
<xs:sequence>
<xs:element name= "ECU-FUNC" type= "ECU-FUNC"
maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:group name= «ELEMENT-ID»> xs:sequence <xs:element name=«SHORT-NAME» type=«SHORT-NAME»/> <xs:element name=«LONG-NAME» type=«LONG-NAME» minOccurs=«0»/> <xs:element name= «DESC» type= «DESCRIPTION» minOccurs=«0»/> </xs:sequence> </xs:group> <xs:complexType name=«EMAIL»> xs:simpleContent <xs:extension base= «xs:string»/> </xs:simpleContent> </xs:complexType> <xs:complexType name=«ENABLE-CONDITIONS»> xs:complexContent <xs:extension base=«ASSIGNABLE»/> </xs:complexContent> </xs:complexType> <xs:complexType name=«ERR-CLASS»> xs:complexContent <xs:extension base=«ASSIGNABLE»/> </xs:complexContent> </xs:complexType> <xs:group name=«EVALUABLE-ENTITY»> xs:sequence xs:choice <xs:element name= «V» type= «xs:double»/> <xs:element name= «VT» type= «TEXT»/> <xs:element name=«VB» type=«xs:boolean»/> </xs:choice> <xs:element name=«UNIT-REF» type=«LINK» minOccurs=«0»/> </xs:sequence> </xs:group> <xs:complexType name= «EXCLUSION»> xs:complexContent <xs:extension base=«ASSIGNABLE»/> </xs:complexContent> </xs:complexType> <xs:complexType name= «EXCLUSIONS»> xs:sequence <xs:element name= «EXCLUSION» type= «EXCLUSION» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«EXPLANATION»> xs:sequence <xs:element name= «DESC» type= «DESCRIPTION»/> <xs:element name=«DATA-DECLARATION-REFS» type=«DATA- DECLARATION-REFS» minOccurs=«0»/> </xs:sequence> </xs:complexType> <xs:group name= «EXPR»> xs:choice <xs:element ref=«OPERAND»/> <xs:element ref=» OP«/> </xs:choice> </xs:group> <xs:complexType name=»EXTERNAL-DOC«> xs:simpleContent <xs:extension base= „xs:string“> <xs:attribute name= „HREF“ type= „xs:anyURI“ use=»required«/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name=»EXTERNAL-DOCS«> xs:sequence <xs:element name=»EXTERNAL-DOC» type=«EXTERNAL-DOC» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«FAULT-CLASSIFICATION»> xs:sequence xs:choice <xs:element name=«ERR-CLASS» type=«ERR-CLASS»/> <xs:element name=«MIL-RELEVANCE» type=«MIL-RELEVANCE»/> </xs:choice> <xs:element name=«MIL-DEBOUNCE-GROUP» type=«MIL-DEBOUNCE-GROUP» minOccurs=«0»/> </xs:sequence> </xs:complexType> <xs:complexType name=«FAULT-CODE»> xs:complexContent <xs:extension base=«ASSIGNABLE»/> </xs:complexContent> </xs:complexType> <xs:complexType name=«FAULT-DEBOUNCE»> xs:complexContent <xs:extension base=«ASSIGNABLE»/> </xs:complexContent> </xs:complexType> <xs:complexType name=«FAULT-DETECTION»> xs:sequence <xs:group ref=» ELEMENT-ID«/> <xs:element name=»GENERIC-TYPE» type=«GENERIC-TYPE» minOccurs=«0»/> <xs:element name=«MON-STRATEGY» type=«MON-STRATEGY» minOccurs=«0»/> <xs:element name=«FAULT-DETECTION-CRITERIA» type=«FAULT- DETECTION-CRITERIA» minOccurs=«0»/> <xs:element name=«ENABLE-CONDITIONS» type=«ENABLE-CONDITIONS» nillable=«true» minOccurs=«0»/> <xs:element name=«FAULT-DEBOUNCE» type=«FAULT-DEBOUNCE» nillable=«true» minOccurs=«0»/> <xs:element name=«MON-FREQUENCY» type=«MON-FREQUENCY» minOccurs=«0»/> <xs:element name=«OK-DETECTION-CRITERIA» type=«OK-DETECTION- CRITERIA» nillable=«true» minOccurs=«0»/> <xs:element name=«OK-ENABLE-CONDITIONS» type=«OK-ENABLE- CONDITIONS» nillable=«true» minOccurs=«0»/> <xs:element name=«OK-DEBOUNCE» type=«OK-DEBOUNCE» nillable=«true» minOccurs=«0»/> <xs:element name=«DISABLE-REPORT-ONLY» type=«DISABLE- REPORT-ONLY» minOccurs=«0»/> <xs:element name=«DISABLE-FULLY» type=«DISABLE-FULLY» minOccurs=«0»/> <xs:element name=«LEGISLATIONS» type=«LEGISLATIONS» nillable=«true» minOccurs=«0»/> <xs:element name= «SERVICE-06» type= «SERVICE-06» minOccurs=«0»/> </xs:sequence> <xs:attributeGroup ref=«ID-ATTRIBUTE»/> </xs:complexType> <xs:complexType name=«FAULT-DETECTION-BASE»> xs:complexContent <xs:restriction base=«FAULT-DETECTION»> xs:sequence <xs:group ref=» ELEMENT-ID«/> <xs:element name=»GENERIC-TYPE» type=«GENERIC-TYPE»/>
<xs:element name="MON-STRATEGY" type="MON-
STRATEGY«/>
<xs:element name=»FAULT-DETECTION-CRITERIA»
type=«FAULT-DETECTION-CRITERIA»/>
<xs:element name=«ENABLE-CONDITIONS» type=«ENABLE-
CONDITIONS» nillable=«true»/>
<xs:element name=«FAULT-DEBOUNCE» type=«FAULT-
DEBOUNCE» nillable=«true»/>
<xs:element name=«MON-FREQUENCY» type=«MON-
FREQUENCY»/>
<xs:element name=«OK-DETECTION-CRITERIA»
type=«OK-DETECTION-CRITERIA» nillable=«true»/>
<xs:element name=«OK-ENABLE-CONDITIONS»
type=«OK-ENABLE-CONDITIONS» nillable=«true»/>
<xs:element name=«OK-DEBOUNCE» type=«OK-DEBOUNCE»
nillable=«true»/>
<xs:element name=«DISABLE-REPORT-ONLY»
type=«DISABLE-REPORT-ONLY» minOccurs=«0»/>
<xs:element name=«DISABLE-FULLY» type=«DISABLE
FULLY» minOccurs=«0»/>
<xs:element name=«LEGISLATIONS»
type=«LEGISLATIONS» nillable=«true»/>
<xs:element name= «SERVICE-06» type= «SERVICE-06»
minOccurs=«0»/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name=«FAULT-DETECTION-CRITERIA»>
xs:complexContent
<xs:extension base=«ASSIGNABLE»/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name=«FAULT-DETECTIONS»>
xs:sequence
<xs:element name=«FAULT-DETECTION» type=«FAULT-DETECTION»
maxOccurs=«unbounded»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«FAULT-DETECTIONS-BASE»>
xs:complexContent
<xs:restriction base=«FAULT-DETECTIONS»>
xs:sequence
<xs:element name=«FAULT-DETECTION» type=«FAULT-
DETECTION-BASE» maxOccurs=«unbounded»/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name=«FAULT-IDENTIFICATION»>
xs:sequence
<xs:element name=«LEGAL-CODE» type=«FAULT-CODE»
nillable=«true»/>
<xs:element name= «CUSTOM-CODES» type= «CUSTOM-CODES»
nillable=«true»/>
<xs:element name=«FAULT-TYPE» type=«FAULT-TYPE» minOccurs=«0»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«FAULT-SYMPTOM»>
xs:sequence
<xs:group ref=» ELEMENT-ID«/>
<xs:element name=»COMPANY-DATA-REF» type=«LINK»/>
<xs:element name= «ECU-FUNCS» type= «ECU-FUNCS» minOccurs=«0»/>
<xs:element name=«CONFIGURATION» type=«CONFIGURATION»
minOccurs=«0»/>
<xs:element name=«FAULT-IDENTIFICATION» type=«FAULT-
IDENTIFICATION» minOccurs=«0»/>
<xs:element name= «MON-COMPONENT» type= «MON-COMPONENT»
minOccurs=«0»/>
<xs:element name=«FAULT-CLASSIFICATION» type=«FAULT-
CLASSIFICATION» minOccurs=«0»/>
<xs:element name=«RATIO-GROUPS» type=«RATIO-GROUPS»
minOccurs=«0»/>
<xs:element name=«READINESS-GROUP» type=«READINESS-GROUP»
minOccurs=«0»/>
<xs:element name=«FAULT-DETECTIONS» type=«FAULT-DETECTIONS»
minOccurs=«0»/>
<xs:element name=«CENTRAL-CALIBRATION-INFOS» type=«CENTRAL-
CALIBRATION-INFOS» minOccurs=«0»/>
<xs:element name=«INHIBITIONS» type=«INHIBITIONS»
minOccurs=«0»/>
<xs:element name=«SUBSTITUTION-FUNCTION» type=«SUBSTITUTION-
FUNCTION» minOccurs=«0»/>
<xs:element name= «PROTECTIVE-FUNCTION» type= «PROTECTIVE-
FUNCTION» minOccurs=«0»/>
<xs:element name=«SIMULATION-METHOD» type=«SIMULATION-METHOD»
minOccurs=«0»/>
<xs:element name=«PARENT-REF» type=«LINK» minOccurs=«0»/>
<xs:any names pace=«##other» processContents=«lax»
minOccurs=«0»/>
</xs:sequence>
<xs:attribute name=«DESC-STATE» type=«DESC-STATE» use=«required»/>
<xs:attribute name=«DESC-EXTENT» type=«DESC-EXTENT» use=«required»/>
<xs:attributeGroup ref=«ID-ATTRIBUTE»/>
<xs:attributeGroup ref=«SI-ATTRIBUTE»/>
<xs:attributeGroup ref=«OID-ATTRIBUTE»/>
<xs:attribute ref=» xml:lang«/>
</xs:complexType>
<xs:complexType name=»FAULT-SYMPTOM-3RD-PARTY«>
xs:sequence
<xs:element name=»SHORT-NAME» type=«SHORT-NAME»/>
<xs:element name=«THIRD-PARTY» type=«THIRD-PARTY»/>
</xs:sequence>
<xs:attributeGroup ref=«ID-ATTRIBUTE»/>
</xs:complexType>
<xs:complexType name=«FAULT-SYMPTOM-3RD-PARTYS»>
xs:sequence
<xs:element name=«FAULT-SYMPTOM-3RD-PARTY» type=«FAULT-SYMPTOM-
3RD-PARTY» minOccurs=«0» maxOccurs=«unbounded»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«FAULT-SYMPTOM-BASE»>
xs:complexContent
<xs:restriction base=«FAULT-SYMPTOM»>
xs:sequence
<xs:group ref=» ELEMENT-ID«/>
<xs:element name=»COMPANY-DATA-REF» type=«LINK»/>
<xs:element name= «ECU-FUNCS» type= «ECU-FUNCS»/>
<xs:element name=«CONFIGURATION»
type=«CONFIGURATION» minOccurs=«0»/>
<xs:element name=«FAULT-IDENTIFICATION»
type=«FAULT-IDENTIFICATION»/>
<xs:element name= «MON-COMPONENT» type= «MON-
COMPONENT»/>
<xs:element name=«FAULT-CLASSIFICATION»
type=«FAULT-CLASSIFICATION»/>
<xs:element name=«RATIO-GROUPS» type=«RATIO-
GROUPS» minOccurs=«0»/>
<xs:element name=«READINESS-GROUP»
type=«READINESS-GROUP» minOccurs=«0»/>
<xs:element name=«FAULT-DETECTIONS» type=«FAULT-
DETECTIONS-BASE»/>
<xs:element name=«CENTRAL-CALIBRATION-INFOS»
type=«CENTRAL-CALIBRATION-INFOS» minOccurs=«0»/>
<xs:element name=«INHIBITIONS» type=«INHIBITIONS»
minOccurs=«0»/>
<xs:element name=«SUBSTITUTION-FUNCTION»
type=«SUBSTITUTION-FUNCTION» minOccurs=«0»/>
<xs:element «PROTECTIVE-FUNCTION»
type=«PROTECTIVE-FUNCTION» minOccurs=«0»/>
<xs:element name=«SIMULATION-METHOD»
type=«SIMULATION-METHOD» minOccurs=«0»/>
<xs:any namespace=«##other» processContents=«lax»
minOccurs=«0»/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name=«FAULT-SYMPTOM-EXCH-DESC» type=«FAULT-SYMPTOM-EXCH-DESC»>
xs:annotation
xs:documentation
Robert Bosch GmbH and Continental
Automotive GmbH.
All rights reserved, also regarding any disposal, exploitation, reproduction,
editing, distribution, as well as in the event of applications for industrial property
rights. </xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name=«FAULT-SYMPTOM-EXCH-DESC»>
xs:sequence
<xs:element name=«ADMIN-DATA» type=«ADMIN-DATA»/>
<xs:element name=«COMPANY-DATAS» type=«COMPANY-DATAS»/>
<xs:element name=«DATA-DICTIONARY» type=«DATA-DICTIONARY»/>
<xs:element name=«VARIABLE-DESCRIPTIONS» type=«VARIABLE-
DESCRIPTIONS»/>
<xs:element name=«FAULT-SYMPTOMS» type=«FAULT-SYMPTOMS»/>
<xs:element name=«FAULT-SYMPTOM-3RD-PARTYS» type=«FAULT-
SYMPTOM-3RD-PARTYS»/>
<xs:element name= «SERVICE-06-IDS» type= «SERVICE-06-IDS»/>
<xs:element name= «FIDS» type= «FIDS»/>
<xs:element name=«AUXILIARY-OBJECTS» type=«AUXILIARY-OBJECTS»/>
<xs:element name=«MASKS» type=«MASKS»/>
<xs:element name=«TEXT-MAPPINGS» type=«TEXT-MAPPINGS»/>
<xs:any namespace=«##other» processContents=«lax»
minOccurs=«0»/>
</xs:sequence>
<xs:attribute name=«VERSION» type=«VERSION» use=«required»/>
<xs:attribute ref=» xml:lang«/>
<xs:attribute ref=» xml:base«/>
</xs:complexType>
<xs:complexType name=»FAULT-SYMPTOM-REFS«>
xs:sequence
<xs:element name=»FAULT-SYMPTOM-REF» type=«MASKED-LINK»
maxOccurs=«unbounded»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«FAULT-SYMPTOMS»>
xs:sequence
<xs:element name=«FAULT-SYMPTOM» type=«FAULT-SYMPTOM»
minOccurs=«0» maxOccurs=«unbounded»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«FAULT-TYPE»>
xs:complexContent
<xs:extension base=«ASSIGNABLE»/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name=«FAX»>
xs:simpleContent
<xs:extension base= «xs:string»/>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name= «FID»>
xs:sequence
<xs:group ref=» ELEMENT-ID«/>
<xs:element name=»FID-TYPE» type=«FID-TYPE»/>
<xs:element name= «ECU-FUNC» type= «ECU-FUNC»/>
<xs:element name=«FAULT-SYMPTOM-REFS» type=«FAULT-SYMPTOM-REFS»
minOccurs=«0»/>
<xs:element name=«AUXILIARY-OBJECT-REFS» type=«AUXILIARY-
OBJECT-REFS» minOccurs=«0»/>
<xs:element name=«EXPLANATION» type=«EXPLANATION»
minOccurs=«0»/>
</xs:sequence>
<xs:attributeGroup ref=«ID-ATTRIBUTE»/>
</xs:complexType>
<xs:complexType name= «FID-REFS»>
xs:sequence
<xs:element name=«FID-REF» type=«LINK» maxOccurs=«unbounded»/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name=«FID-TYPE»>
<xs:restriction base= «xs:string»>
<xs:enumeration value=«CALCULATION»/>
<xs:enumeration value=«VALIDATION»/>
<xs:enumeration value =«OTHER»/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name= «FIDS»>
xs:sequence
<xs:element name= «FID» type= «FID» minOccurs=«0»
maxOccurs=«unbounded»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«FROM-STATE»>
xs:sequence
<xs:element name=«DATA-DECLARATION-REF» type=«LINK»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«GENERIC-TYPE»>
xs:complexContent
<xs:extension base=«SELECTABLE»/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name=«HOMEPAGE»>
xs:simpleContent
<xs:extension base= «xs:string»/>
</xs:simpleContent>
</xs:complexType>
<xs:attributeGroup name=«ID-ATTRIBUTE»>
<xs:attribute name=«ID» type=«xs:ID» use=«required»/>
</xs:attributeGroup>
<xs:simpleType name=«INFO-TYPE»>
<xs:restriction base=«xs:NMTOKEN»/>
</xs:simpleType>
<xs:complexType name=«INHIBITIONS»>
xs:sequence
<xs:element name=«BY-SYMPTOM» type=«BY-SYMPTOM» minOccurs=«0»/>
<xs:element name=«BY-FUNCTION» type=«BY-FUNCTION»
minOccurs=«0»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«INITIAL-STATE»>
xs:sequence
<xs:element name=«DATA-DECLARATION-REF» type=«LINK»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«LEGISLATION»>
xs:sequence
<xs:element name=«LAW» type=«xs:string»/>
<xs:element name= «SECTION» type= «xs:string»/>
<xs:element name=«MCL-STRATEGY» type=«MCL-STRATEGY»
minOccurs=«0»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«LEGISLATIONS»>
xs:sequence
<xs:element name=«LEGISLATION» type=«LEGISLATION»
maxOccurs=«unbounded»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«LlNK»>
<xs:attributeGroup ref=«LINK-ATTR»/>
</xs:complexType>
<xs:attributeGroup name=«LINK-ATTR»>
<xs:attribute name=«ID-REF» type=«xs:IDREF» use=«required»/>
</xs:attributeGroup>
<xs:complexType name=«LONG-NAME»>
xs:simpleContent
<xs:restriction base= «TEXT»/>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name=«MASK»>
xs:sequence
<xs:group ref=«ELEMENT-ID»/>
</xs:sequence>
<xs:attributeGroup ref=«ID-ATTRIBUTE»/>
</xs:complexType>
<xs:complexType name=«MASKED-LINK»>
xs:complexContent
<xs:extension base=«LINK»>
xs:sequence
<xs:element name=«MASK-REF» type=«LINK»
minOccurs=«0»/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name=«MASKS»>
xs:sequence
<xs:element name=«MASK» type=«MASK» minOccurs=«0»
maxOccurs=«unbounded»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«MCL-STRATEGY»>
xs:complexContent
<xs:extension base=«SELECTABLE»/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name=«MIL-DEBOUNCE-GROUP»>
xs:complexContent
<xs:extension base=«ASSIGNABLE»/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name=«MIL-RELEVANCE»>
xs:complexContent
<xs:extension base=«ASSIGNABLE»/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name= «MON-COMPONENT»>
xs:complexContent
<xs:extension base=«SELECTABLE»/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name=«MON-FREQUENCY»>
xs:complexContent
<xs:extension base=«SELECTABLE»/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name=«MON-STRATEGY»>
xs:complexContent
<xs:extension base=«SELECTABLE»/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name=«OBDMID»>
<xs:complexContent>
<xs:extension base="ASSIGNABLE"/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="OBDTID">
<xs:complexContent>
<xs:extension base="ASSIGNABLE">
<xs:sequence>
<xs:element name="OBDUSID" type="OBDUSID"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="OBDTIDS">
<xs:sequence>
<xs:element name="OBDTID" type="OBDTID" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="OBDUSID">
<xs:complexContent>
<xs:extension base="ASSIGNABLE"/>
</xs:complexContent>
</xs:complexType>
<xs:attributeGroup name="OID-ATTRIBUTE">
<xs:attribute name="OID" type="xs:string" use="optional"/>
</xs:attributeGroup>
<xs:complexType name="OK-DEBOUNCE">
<xs:complexContent>
<xs:extension base="ASSIGNABLE"/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="OK-DETECTION-CRITERIA">
<xs:complexContent>
<xs:extension base="ASSIGNABLE"/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="OK-ENABLE-CONDITIONS">
<xs:complexContent>
<xs:extension base="ASSIGNABLE"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="OP" type="OPERATION"/>
<xs:element name="OPERAND" type="OPERAND" abstract="true"/>
<xs:complexType name="OPERAND" abstract="true"/>
<xs:complexType name="OPERATION">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:group ref=" EXPR"/>
</xs:sequence>
<xs:attribute name="OPERATOR" type="OPERATORS" use="required"/>
</xs:complexType>
<xs:simpleType name="OPERATORS">
<xs:restriction base="xs:NMTOKEN"/>
</xs:simpleType>
<xs:complexType name= "PHONE">
<xs:simpleContent>
<xs:extension base= "xs:string"/>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="PHYSICAL-DIMENSION">
<xs:sequence>
<xs:group ref=" ELEMENT-ID"/>
<xs:element name="LENGTH-EXP" type="xs:int" minOccurs="0"/>
<xs:element name="MASS-EXP" type="xs:int" minOccurs="0"/>
<xs:element name= "TIME-EXP" type= "xs:int" minOccurs="0"/>
<xs:element name= "CURRENT-EXP" type= "xs:int" minOccurs="0"/>
<xs:element name="TEMPERATURE-EXP" type="xs:int"
minOccurs=«0»/> <xs:element name=«MOLAR-AMOUNT-EXP» type=«xs:int» minOccurs=«0»/> <xs:element name=«LUMINOUS-INTENSITY-EXP» type=«xs:int» minOccurs=«0»/> </xs:sequence>
<xs:attributeGroup ref="ID-ATTRIBUTE"/>
</xs:complexType>
<xs:complexType name="PHYSICAL-DIMENSIONS">
<xs:sequence>
<xs:element name="PHYSICAL-DIMENSION" type="PHYSICAL-DIMENSION"
maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name= «PROJECT»>
<xs:sequence>
<xs:element name="NAME" type="xs:string"/>
<xs:element name="SW-BASELINE" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name= "PROTECTIVE-FUNCTION">
<xs:sequence>
<xs:element name= "DESC" type= "DESCRIPTION"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="RATIO-GROUP">
<xs:complexContent>
<xs:extension base="ASSIGNABLE"/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="RATIO-GROUPS">
<xs:sequence>
<xs:element name="RATIO-GROUP" type="RATIO-GROUP"
maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«READINESS-GROUP»> xs:complexContent <xs:extension base=«ASSIGNABLE»/> </xs:complexContent> </xs:complexType> <xs:complexType name= «REQUIRED-CONDITION»> xs:complexContent <xs:extension base=«ASSIGNABLE»/> </xs:complexContent> </xs:complexType> <xs:complexType name= «RESOURCES»> xs:sequence <xs:element name=«DATA-DESCRIPTION» type=«xs:string»/> <xs:element name=«CALIBRATION» type=«xs:string» minOccurs=«0»/> <xs:element name=«EXTERNAL-DOCS» type=«EXTERNAL-DOCS» minOccurs=«0»/> </xs:sequence> </xs:complexType> <xs:complexType name= «ROLE»> xs:simpleContent <xs:extension base= «xs:string»/> </xs:simpleContent> </xs:complexType> <xs:complexType name= «ROLES»> xs:sequence <xs:element name= «ROLE» type= «ROLE» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«SELECTABLE» abstract=«true»> xs:sequence <xs:element name= «VT» type= «TEXT»/> <xs:element name= «DESC» type= «DESCRIPTION» minOccurs=«0»/> </xs:sequence> </xs:complexType> <xs:simpleType name=«SEMANTIC»> <xs:restriction base= «xs:string»> <xs:enumeration value=«RAWINFO»/> <xs:enumeration value=«SUMMARY»/> <xs:enumeration value =«SERVICE»/> <xs:enumeration value =«OTHER»/> </xs:restriction> </xs:simpleType> <xs:complexType name= «SERVICE-06»> xs:sequence <xs:element name=«SERVICE-06-ID-REF» type=«LINK» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name= «SERVICE-06-ID»> xs:sequence <xs:element name=«OBDMID» type=«OBDMID»/> <xs:element name=«OBDTIDS» type=«OBDTIDS»/> </xs:sequence> <xs:attributeGroup ref=«ID-ATTRIBUTE»/> </xs:complexType> <xs:complexType name= «SERVICE-06-IDS»> xs:sequence <xs:element name= «SERVICE-06-ID» type= «SERVICE-06-ID» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«SHORT-NAME»> xs:simpleContent <xs:extension base=«SHORT-NAME-TEXT»/> </xs:simpleContent> </xs:complexType> <xs:simpleType name=«SHORT-NAME-TEXT»> <xs:restriction base= «xs:string»> <xs:pattern value=«[a-zA-Z0-9_]{1,128}»/> </xs:restriction> </xs:simpleType> <xs:attributeGroup name=«SI-ATTRIBUTE»> <xs:attribute name=«SI» type=«SEMANTIC» use=«required»/> </xs:attributeGroup> <xs:complexType name=«SIMPLE-VARIABLE»> xs:complexContent <xs:extension base=«ASSIGNABLE»/> </xs:complexContent> </xs:complexType> <xs:complexType name=«SIMULATION-METHOD»> xs:complexContent <xs:extension base=«SELECTABLE»/> </xs:complexContent> </xs:complexType> <xs:complexType name=«STATE-COMPUTATION»> xs:complexContent <xs:extension base=«ASSIGNABLE»/> </xs:complexContent> </xs:complexType> <xs:complexType name=«STATE-GRAPH»> xs:sequence <xs:element name=«STATES» type=«DATA-DECLARATION-REFS»/> <xs:element name=«INITIAL-STATE» type=«INITIAL-STATE»/> <xs:element name=«STATE-TRANSITIONS» type=«STATE-TRANSITIONS»/> <xs:element name=«STATE-COMPUTATION» type=«STATE-COMPUTATION» minOccurs=«0»/> </xs:sequence> </xs:complexType> <xs:complexType name=«STATE-TRANSITION»> xs:sequence <xs:element name=«FROM-STATE» type=«FROM-STATE»/> <xs:element name=«TO-STATE» type=«TO-STATE»/> <xs:element name= «REQUIRED-CONDITION» type= «REQUIRED- CONDITION»/> </xs:sequence> </xs:complexType> <xs:complexType name=«STATE-TRANSITIONS»> xs:sequence <xs:element name=«STATE-TRANSITION» type=«STATE-TRANSITION» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«SUBSTITUTION-FUNCTION»> xs:sequence <xs:element name= «DESC» type= «DESCRIPTION»/> </xs:sequence> </xs:complexType> <xs:complexType name=«TEAM-MEMBER»> xs:sequence <xs:group ref=» ELEMENT-ID«/> <xs:element name= „ROLES“ type= „ROLES“ minOccurs=»0«/> <xs:element name=»DEPARTMENT» type=«DEPARTMENT» minOccurs=«0»/> <xs:element name=«ADDRESS» type=«ADDRESS» minOccurs=«0»/> <xs:element name=«ZIP» type=«ZIP» minOccurs=«0»/> <xs:element name=«CITY» type=«CITY» minOccurs=«0»/> <xs:element name= «PHONE» type= «PHONE» minOccurs=«0»/> <xs:element name=«FAX» type=«FAX» minOccurs=«0»/> <xs:element name=«EMAIL» type=«EMAIL» minOccurs=«0»/> <xs:element name=«HOMEPAGE» type=«HOMEPAGE» minOccurs=«0»/> </xs:sequence> </xs:complexType> <xs:complexType name=«TEAM-MEMBERS»> xs:sequence <xs:element name=«TEAM-MEMBER» type=«TEAM-MEMBER» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name= «TEXT»> xs:simpleContent <xs:extension base= «xs:string»> <xs:attributeGroup ref=«TI-ATTRIBUTE»/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name=«TEXT-MAP»> xs:sequence <xs:element name= «TI» type= «xs:string»/> <xs:element name= «TEXT» type= «xs:string»/> </xs:sequence> </xs:complexType> <xs:complexType name=«TEXT-MAPPING»> xs:sequence <xs:element name=«COMPANY-DATA-REF» type=«LINK»/> <xs:element name=«TEXT-MAPS» type=«TEXT-MAPS»/> </xs:sequence> <xs:attributeGroup ref=«SI-ATTRIBUTE»/> <xs:attribute ref=» xml:lang«/> </xs:complexType> <xs:complexType name=»TEXT-MAPPINGS«> xs:sequence <xs:element name=»TEXT-MAPPING» type=«TEXT-MAPPING» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«TEXT-MAPS»> xs:sequence <xs:element name=«TEXT-MAP» type=«TEXT-MAP» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«THIRD-PARTY»> xs:sequence <xs:element name=«COMPANY-DATA-REF» type=«LINK»/> <xs:element name=«FAULT-SYMPTOM-3RD-PARTY-SHORT-NAME» type=«SHORT-NAME»/> </xs:sequence> </xs:complexType> <xs:attributeGroup name=«TI-ATTRIBUTE»> <xs:attribute name=«TI» type=«xs:string» use=«optional»/> </xs:attributeGroup> <xs:complexType name=«TO-STATE»> xs:sequence <xs:element name=«DATA-DECLARATION-REF» type=«LINK»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name= "UNIT">
<xs:sequence>
<xs:group ref=" ELEMENT-ID"/>
<xs:element name="DISPLAY-NAME" type="TEXT"/>
<xs:element name="FACTOR-SI-TO-UNIT" type="xs:double"
minOccurs=«0»/> <xs:element name= «OFFSET-SI-TO-UNIT» type= «xs:double» minOccurs=«0»/> <xs:element name=«PHYSICAL-DIMENSION-REF» type=«LINK» minOccurs=«0»/> </xs:sequence> <xs:attributeGroup ref=«ID-ATTRIBUTE»/> </xs:complexType> <xs:complexType name=«UNIT-GROUP»> xs:sequence <xs:group ref=«ELEMENT-ID»/> <xs:element name=«CATEGORY» type=«UNIT-GROUP-CATEGORY»/> <xs:element name= «UNIT-REFS» type= «UNIT-REFS» minOccurs=«0»/> </xs:sequence> </xs:complexType> <xs:simpleType name=«UNIT-GROUP-CATEGORY»> <xs:restriction base= «xs:string»> <xs:enumeration value=«COUNTRY»/> <xs:enumeration value =«EQUIV-UNITS»/> </xs:restriction> </xs:simpleType> <xs:complexType name=«UNIT-GROUPS»> xs:sequence <xs:element name=«UNIT-GROUP» type=«UNIT-GROUP» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name= «UNIT-REFS»> xs:sequence <xs:element name=«UNIT-REF» type=«LINK» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name= «UNIT-SPEC»> xs:sequence <xs:element name=«UNIT-GROUPS» type=«UNIT-GROUPS» minOccurs=«0»/> <xs:element name= «UNITS» type= «UNITS» minOccurs=«0»/> <xs:element name=«PHYSICAL-DIMENSIONS» type=«PHYSICAL- DIMENSIONS» minOccurs=«0»/> </xs:sequence> </xs:complexType> <xs:complexType name= «UNITS»> xs:sequence <xs:element name= «UNIT» type= «UNIT» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«VALUE»> xs:sequence <xs:group ref=«EVALUABLE-ENTITY»/> </xs:sequence> </xs:complexType> <xs:complexType name=«VARIABLE-DESCRIPTION»> xs:sequence <xs:group ref=» ELEMENT-ID«/> <xs:element name=»COMPANY-DATA-REF» type=«LINK»/> <xs:element name= «ECU-FUNCS» type= «ECU-FUNCS» minOccurs=«0»/> <xs:element name=«CONFIGURATION» type=«CONFIGURATION» minOccurs=«0»/> <xs:element name=«DATA-DECLARATION-REF» type=«LINK» minOccurs=«0»/> xs:choice <xs:element name=«SIMPLE-VARIABLE» type=«SIMPLE-VARIABLE» minOccurs=«0»/>
<xs:element name="BIT-FIELD-VARIABLE" type="BIT-FIELD-
VARIABLE» minOccurs=«0»/> <xs:element name=«STATE-GRAPH» type=«STATE-GRAPH» minOccurs=«0»/> </xs:choice> <xs:element name=«PARENT-REF» type=«LINK» minOccurs=«0»/> <xs:any names pace=«##other» processContents=«lax» minOccurs=«0»/> </xs:sequence> <xs:attribute name=«DESC-STATE» type=«DESC-STATE» use=«required»/>
<xs:attribute name="DESC-EXTENT" type="DESC-EXTENT" use="required"/>
<xs:attributeGroup ref="ID-ATTRIBUTE"/>
<xs:attributeGroup ref="SI-ATTRIBUTE"/>
<xs:attributeGroup ref="OID-ATTRIBUTE"/>
<xs:attribute ref=" xml:lang"/>
</xs:complexType>
<xs:complexType name="VARIABLE-DESCRIPTION-BASE">
<xs:complexContent>
<xs:restriction base="VARIABLE-DESCRIPTION">
<xs:sequence>
<xs:group ref="ELEMENT-ID"/>
<xs:element name="COMPANY-DATA-REF" type="LINK"/>
<xs:element name= "ECU-FUNCS" type= "ECU-FUNCS"/>
<xs:element name="CONFIGURATION"
type=«CONFIGURATION» minOccurs=«0»/> <xs:element name=«DATA-DECLARATION-REF» type=«LINK»/> xs:choice <xs:element name=«SIMPLE-VARIABLE» type=«SIMPLE-VARIABLE»/> <xs:element name=«BIT-FIELD-VARIABLE» type=«BIT-FIELD-VARIABLE»/> <xs:element name=«STATE-GRAPH» type=«STATE GRAPH»/> </xs:choice> <xs:any names pace=«##other» processContents=«lax» minOccurs=«0»/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name=«VARIABLE-DESCRIPTIONS»> xs:sequence <xs:element name=«VARIABLE-DESCRIPTION» type=«VARIABLE- DESCRIPTION» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:simpleType name= «VERSION»> <xs:restriction base= «xs:string»> <xs:enumeration value =«2.0.0»/> </xs:restriction> </xs:simpleType> <xs:complexType name=«ZIP»> xs:simpleContent <xs:extension base= «xs:string»/> </xs:simpleContent> </xs:complexType> </xs:schema>
A.2 Список отображения элементов FXD XML-схемы
В таблице A.1 перечислены элементы FXD XML-схемы, приведенные в настоящем стандарте.
Примечание — Ссылочные элементы не перечислены (например, FAULT-SYMPTOM-REFS).
Список соответствия элементов FXD XML-схемы настоящему стандарту
| Элемент FXD XML-схемы | Атрибуты | Пункт | Заголовок пункта в настоящем стандарте |
| ABSTRACT-SYNTAX | 4.3.2.1 | Основные требования | |
| 4.5.2 | Формальное описание алгоритмов диагностики | ||
| 7.4.2 | COMPUTATIONS | ||
| ADMIN-DATA | 7.2.1 | Основные положения | |
| AUXILIARY-OBJECT | ID | 7.10 | AUXILIARY-OBJECTS |
| AUXILIARY-OBJECTS | 7.10 | AUXILIARY-OBJECTS | |
| BIT-FIELD | 7.5.1 | Основные положения | |
| BIT-FIELD-COMPUTATION | 7.5.8 | BIT-FIELD-VARIABLE | |
| BIT-FIELD-VARIABLE | 7.5.1 | Основные положения | |
| 7.5.8 | BIT-FIELD-VARIABLE | ||
| BIT-MASK | 7.5.8 | BIT-FIELD-VARIABLE | |
| BY-FUNCTION | 7.6.13.2 | INHIBITIONS по функциям | |
| BY-SYMPTOM | 7.6.13.1 | INHIBITIONS по симптомам | |
| CALIBRATION | 7.2.5 | RESOURCES | |
| CENTRAL-CALIBRATION-NFO | 7.6.12 | CENTRAL-CALIBRATION-INFOS | |
| CENTRAL-CALIBRATION-INFOS | 7.6.12 | CENTRAL-CALIBRATION-INFOS | |
| COMPANY-DATA | ID | 4.5.3 | Механизм наследования значений для поддержки вариантов использования |
| 7.3.1 | Основные положения | ||
| 7.3.2 | COMPANY-DATA | ||
| COMPANY-DATAS | 7.3 | COMPANY-DATAS | |
| COMPU-CONST | 4.5.2 | Формальное описание алгоритмов диагностики | |
| COMPU-VAR | 4.5.2 | Формальное описание алгоритмов диагностики | |
| COMPUTATION | xml: lang ID | 4.5.2 | Формальное описание алгоритмов диагностики |
| 7.4.2 | COMPUTATIONS | ||
| 7.5.1 | Основные положения | ||
| COMPUTATIONS | 7.4.2 | COMPUTATIONS | |
| CONFIGURATION | 7.6.5 | CONFIGURATION | |
| CUSTOM-CODE | 7.6.6.2 | CUSTOM-CODES | |
| CUSTOM-CODES | xsi:nil | 7.6.6.2 | CUSTOM-CODES |
| DATA | 7.4.1 | DATA-DECLARATIONS | |
| DATA-DECLARATION | ID | 4.3.2.1 | Основные требования |
| 6.5 | Ссылки на переменные ЭБУ и калибровочные метки | ||
| 7.4.1 | DATA-DECLARATIONS | ||
| 7.5.1 | Основные положения | ||
| DATA-DECLARATIONS | 7.4.1 | DATA-DECLARATIONS | |
| DATA-DESCRIPTION | 7.2.5 | RESOURCES | |
| DATA-DICTIONARY | 7.4 | DATA-DICTIONARY | |
| DATA-NAME | 7.4.1 | DATA-DECLARATIONS | |
| DATA-TYPE | 7.5.1 | Основные положения | |
| DATA-VALUE | 7.6.5 | Элемент CONFIGURATION | |
| DATE | 7.2.6 | Элемент DOC-REVISIONS | |
| DESC | TI | 4.5.2 | Формальное описание алгоритмов диагностики |
| 6.4 | Ссылки на внешние документы | ||
| 6.6 | Общие элементы FXD, используемые для идентификации и описания | ||
| 7.9.7 | Элемент EXPLANATION | ||
| DISABLE-FULLY | 7.6.11.14 | DISABLE-FULLY | |
| DISABLE-REPORT-ONLY | 7.6.11.13 | DISABLE-REPORT-ONLY | |
| DISPLAY-NAME | TI | 7.4.1 | DATA-DECLARATIONS |
| 7.4.3 | UNIT-SPEC | ||
| DOC-REVISION | 7.2.6 | DOC-REVISIONS | |
| DOC-REVISIONS | 7.2.6 | DOC-REVISIONS | |
| ECU-FAMILY | 7.2.3 | ECU-FAMILY | |
| ECU-FUNC | 7.5.4.1 | Элемент LONG-NAME | |
| 7.5.4.2 | Элемент VERSION | ||
| 7.5.4 | Элемент ECU-FUNCS | ||
| ECU-FUNCS | 7.5.4 | Элемент ECU-FUNCS | |
| ENABLE-CONDITIONS | xsi:nil | 4.5.3 | Механизм наследования значений для поддержки вариантов использования |
| 7.6.11.5 | ENABLE-CONDITIONS | ||
| ERR-CLASS | 7.6.8.1 | ERR-CLASS | |
| EXCLUSION | 7.6.13.2 | INHIBITIONS по функциям | |
| EXCLUSIONS | 7.6.13.2 | INHIBITIONS по функциям | |
| EXPLANATION | 4.3.2.1 | Основные требования | |
| 4.5.2 | Формальное описание алгоритмов диагностики | ||
| 7.4.2 | COMPUTATIONS | ||
| EXTERNAL-DOC | HREF | 6.4 | Ссылки на внешние документы |
| 7.2.5 | RESOURCES | ||
| EXTERNAL-DOC | 6.4 | Ссылки на внешние документы | |
| 7.2.5 | RESOURCES | ||
| FAULT-CLASSIFICATION | 7.6.8 | FAULT-CLASSIFICATION | |
| FAULT-DEBOUNCE | xsi:nil | 7.6.11.7 | FAULT-DEBOUNCE |
| FAULT-DETECTION | xsi:type ID | 7.6.11 | FAULT-DETECTIONS |
| 7.6.11.1 | Основная информация FAULT-DETECTION | ||
| FAULT-DETECTION-CRITERIA | 4.5.3 | Механизм наследования значений для поддержки вариантов использования | |
| 7.6.11.4 | FAULT-DETECTION-CRITERIA | ||
| FAULT-DETECTIONS | xsi:type | 7.6.11 | FAULT-DETECTIONS |
| FAULT-IDENTIFICATION | 7.6.6 | FAULT-IDENTIFICATION | |
| FAULT-SYMPTOM | xsi:type DESC-STATE DESC-EXTENT xml:lang | 4.4 | Формат FXD и пример |
| 4.5.4 | Реализация наследования значений | ||
| 7.6 | FAULT-SYMPTOMS | ||
| FAULT-SYMPTOM-3RD-PARTY | ID | 7.7 | FAULT-SYMPTOM-3RD-PARTY |
| FAULT-SYMPTOM-3RD-PARTY-SHORT-NAME | 7.7 | FAULT-SYMPTOM-3RD-PARTY | |
| FAULT-SYMPTOM-3RD-PARTYS | 7.7 | FAULT-SYMPTOM-3RD-PARTY | |
| FAULT-SYMPTOM-EXCH-DESC | VERSION xml:base xml:lang | 6.1.10 | Атрибут VERSION (содержание) |
| 6.1.11 | Атрибут xml:base (инфраструктура) | ||
| 6.1.12 | Атрибут xml:lang (инфраструктура) | ||
| FAULT-SYMPTOMS | 7.5.1 | Основные положения | |
| 7.6 | FAULT-SYMPTOMS | ||
| FAULT-TYPE | 7.6.6.3 | FAULT-TYPE | |
| FID | ID | 7.9 | FIDS |
| FID-TYPE | 7.9.3 | FID-TYPE | |
| FIDS | 7.9 | FIDS | |
| FROM-STATE | 7.5.9 | STATE-GRAPH | |
| GENERIC-TYPE | 6.3 | Реестры общего выбора | |
| 7.6.11.16 | GENERIC-TYPE | ||
| INHIBITIONS | 7.6.13 | Информация элемента INHIBITIONS | |
| INITIAL-STATE | 7.5.9 | STATE-GRAPH | |
| LEGAL-CODE | xsi:nil | 7.6.6.1 | Правовой код |
| LEGISLATION | 7.6.11.12 | Ссылка на законодательство в области бортовой диагностики | |
| 7.6.11.12.2 | LEGISLATION | ||
| LEGISLATIONS | xsi:nil | 7.6.11.12.2 | LEGISLATION |
| LONG-NAME | 6.6 | Общие элементы FXD, используемые для идентификации и описания | |
| 7.5.4.1 | LONG-NAME | ||
| 7.5.8 | BIT-FIELD-VARIABLE | ||
| 7.6.4.1 | LONG-NAME | ||
| 7.9.4.1 | LONG-NAME | ||
| MASK | ID | 7.11 | MASKS |
| MASKS | 7.11 | MASKS | |
| MCL-STRATEGY | 6.3 | Реестры общего выбора | |
| 7.6.11.12 | Ссылка на законодательство в области бортовой диагностики | ||
| 7.6.11.12.3 | MCL-STRATEGY | ||
| MIL-DEBOUNCE-GROUP | 7.6.8.3 | MIL-DEBOUNCE-GROUP | |
| MIL-RELEVANCE | 7.6.8.2 | MIL-RELEVANCE | |
| MON-COMPONENT | 6.3 | Реестры общего выбора | |
| 7.6.7 | MON-COMPONENT или система | ||
| MON-FREQUENCY | 6.3 | Реестры общего выбора | |
| 7.6.11.8 | MON-FREQUENCY | ||
| MON-STRATEGY | 7.6.11.3 | MON-STRATEGY | |
| NAME | 7.2.4 | PROJECT | |
| 7.2.5 | RESOURCES | ||
| OBDMID | 7.8 | SERVICE-06-IDS | |
| OBDTID | 7.8 | SERVICE-06-IDS | |
| OBDTIDS | 7.8 | SERVICE-06-IDS | |
| OBDUSID | 7.8 | SERVICE-06-IDS | |
| OK-DEBOUNCE | xsi:nil | 7.6.11.11 | OK-DEBOUNCE |
| OK-DETECTION-CRITERIA | xsi:nil | 7.6.11.9 | OK-DETECTION-CRITERIA |
| OK-ENABLE-CONDITIONS | xsi:nil | 7.6.11.10 | OK-ENABLE-CONDITIONS |
| OP | OPERATOR | 4.5.2 | Формальное описание алгоритмов диагностики |
| OPERAND | 7.4.2 | COMPUTATIONS | |
| PHYSICAL-DIMENSION | ID | 7.4.3 | UNIT-SPEC |
| PHYSICAL-DIMENSIONS | 7.4.1 | DATA-DECLARATIONS | |
| PROJECT | 7.2.4 | PROJECT | |
| PROTECTIVE-FUNCTION | 7.6.15 | PROTECTIVE-FUNCTION | |
| RATIO-GROUP | 6.3 | Реестры общего выбора | |
| 7.6.9 | RATIO-GROUPS | ||
| RATIO-GROUPS | 7.6.9 | RATIO-GROUPS | |
| READINESS-GROUP | 6.3 | Реестры общего выбора | |
| 7.6.10 | READINESS-GROUP | ||
| REQUIRED-CONDITION | 7.5.9 | STATE-GRAPH | |
| RESOURCES | 6.4 | Ссылки на внешние документы | |
| 7.2.5 | RESOURCES | ||
| REVISION-LABEL | 7.2.6 | DOC-REVISIONS | |
| SERVICE-06 | 7.8 | SERVICE-06-IDS | |
| SERVICE-06-ID | ID | 7.8 | SERVICE-06-IDS |
| SERVICE-06-IDS | 7.8 | SERVICE-06-IDS | |
| SHORT-NAME | 4.5.3 | Механизм наследования значений для поддержки вариантов использования | |
| 4.5.4 | Реализация наследования значений | ||
| 6.6 | Общие элементы FXD, используемые для идентификации и описания | ||
| SIMPLE-VARIABLE | 7.5.1 | Основные положения | |
| 7.5.7 | SIMPLE-VARIABLE | ||
| SIMULATION-METHOD | 6.3 | Реестры общего выбора | |
| 7.6.16 | SIMULATION-METHOD | ||
| STATE | 7.2.6 | DOC-REVISIONS | |
| STATE-COMPUTATION | |||
| 7.5.13 | STATE-GRAPH | STATE-GRAPH | |
| 7.5.1 | Основные положения | 7.5.9 | STATE-GRAPH |
| STATE-TRANSITION | |||
| 7.5.1 | Основные положения | STATE-TRANSITIONS | |
| 7.5.9 | STATE-GRAPH | STATES | |
| 7.5.1 | Основные положения | 7.5.9 | STATE-GRAPH |
| SUBSTITUTION-FUNCTION | |||
| 7.6.14 | SUBSTITUTION-FUNCTION | SW-BASELINE | |
| 7.2.4 | PROJECT | 7.2.5 | RESOURCES |
| TEXT-MAP | |||
| 7.12 | TEXT-MAPPINGS | TEXT-MAPPING | xml:lang |
| SI | 7.12 TEXT-MAPPINGS | TEXT-MAPPINGS | |
| 7.12 | TEXT-MAPPINGS | TEXT-MAPS | |
| 7.12 | TEXT-MAPPINGS | THIRD-PARTY | |
| 7.7 | FAULT-SYMPTOM-3RD-PARTYS | TO-STATE | |
| 7.5.9 | STATE-GRAPH | UNIT | ID |
| 7.4.3 | UNIT-SPEC | UNIT-GROUP | |
| 7.4.3 | UNIT-SPEC | UNIT-GROUPS | |
| 7.4.3 | UNIT-SPEC | UNIT-SPEC | |
| 7.4.3 | UNIT-SPEC | UNITS | |
| 7.4.3 | UNIT-SPEC | VARIABLE-DESCRIPTION | xsi:type |
| DESC-STATE | DESC-EXTENT xml:lang ID SI OID 7.5.3 COMPANY-DATA-REF | 7.5 | VARIABLE-DESCRIPTIONS |
| 7.5.3 | COMPANY-DATA-REF | ||
| 7.5.5 | CONFIGURATION | ||
| VARIABLE-DESCRIPTIONS | |||
| 7.5.1 | Основные положения | VT | TI |
| 4.5.2 | Формальное описание алгоритмов диагностики | A.3 Операторы для элемента ABSTRACT-SYNTAX | |
Операторы для элемента ABSTRACT-SYNTAX — это вычисления FXD, которые в основном используются для документирования, а не для оценки; строгий набор текста нежелателен. Тем не менее вычисления или их части можно рассматривать как оцениваемые вычисления. В этом случае требуется подробное определение аргументов операторов и возвращаемых значений. FXD определяет три типа значений:
- значение может быть только истинным или ложным;
- это либо элемент COMPU-CONST/VB, либо результат логической операции;
- значение должно быть числом (целое число или число с плавающей запятой, представляющее в большинстве случаев физическое значение);
- это либо элемент COMPU-CONST/V, либо результат числовой операции;
- значение может быть произвольным текстовым содержимым;
- предполагается, что COMPU-CONST/VT (строки) представляют собой описание значения соответствующего типа.
В таблице A.2 определены оцениваемые типы операторов FXD, т.е. как операторы ведут себя или будут вести себя, если аргументы имеют заданный тип и, если требуется, оценку. Примечание «переменная» означает, что аргумент на самом деле должен быть переменной, а не постоянным значением.
| Функция/оператор | Минимальное/максимальное количество параметров функции | Объяснение | Тип результата | Тип первого параметра | Тип второго параметра | Тип третьего и последующих параметров |
| abs | 1 | Абсолютное значение | Числовой | Числовой | - | - |
| add | 2/с динамической длиной | Дополнение | Числовой | Числовой | Числовой | Числовой |
| and | 2/с динамической длиной | Логическое И | Логический | Логический | Логический | Логический |
| bin/and | 2/с динамической длиной | Бинарное И (bit by bit) | Числовой | Числовой | Числовой | Числовой |
| bin/or | 2/с динамической длиной | Бинарное ИЛИ (bit by bit) | Числовой | Числовой | Числовой | Числовой |
| bin/xor | 2 | Бинарное xor (исключающее ИЛИ bit by bit) | Числовой | Числовой | Числовой | - |
| ceil | 1 | Округление до следующего целого числа, большего или равного значению | Числовой | Числовой | - | - |
| delay a | 2 | Значение задерживается на определенное время. Первый аргумент — это условие, второй аргумент — время задержки. Задержка (n > n_min и n < n_max, 10*мс) выражает ситуацию, когда условие было выполнено, как минимум, в течение 10 мс | Логический | Логический | Числовой | - |
| delta | 1 | Разность между текущим и ранее рассчитанным значениями переменной, например: \Delta(temp) . Это эквивалентно temp — предыдущее (temp) | Числовой | Числовой | - | - |
| div | 2 | Деление | Числовой | Числовой | Числовой | - |
| duration_of b | 1 | Определяет время, в течение которого условие, описываемое первым параметром, постоянно истинно | Числовой | Логический | - | - |
| edge_alternating | 1 | edge_alternating (X): = edge_rising (X) или edge_falling (X). Если происходит нарастание или спад X, выходной сигнал будет истинным в течение одного периода выборки | Логический | Логический | - | - |
| edge_falling | 1 | edge_falling (X): = если (предыдущее (X)! = 0 и X == 0, true, false). Если происходит спад X, выходное значение будет истинным в течение одного периода выборки | Логический | Логический | - | - |
| edge_rising | 1 | edge_rising (X): = если (предыдущее (X) = 0 и X! = 0, true, false). Если происходит нарастание значения X, выходное значение будет истинным в течение одного периода выборки | Логический | Логический | - | - |
| eq c | 2 | Равно. Два значения могут быть равны, только если они имеют один тип | Логический | Любой | Любой | - |
| floor | 1 | Округление до следующего целого числа, меньшего или равного значению | Числовой | Числовой | - | - |
| ge | 2 | Больше либо равно | Логический | Числовой | Числовой | - |
| getbit | 2 | Определяет значение n-го бита в выражении, описанном первым параметром. Положение бита определяется вторым параметром (начиная с 0) | Логический | Числовой | Числовой | - |
| gradient | 2 | Отношение разности между текущим и предыдущим значениями переменной и соответствующей разницы во времени или угле, в которых проводились вычисления, например, gradient(temp,1s). Это эквивалентно \Delta(temp)/1s и (temp-previous(temp))/1s | Числовой | Числовой | Числовой | - |
| gt | 2 | Больше чем | Логический | Числовой | Числовой | |
| if d | 3 | Условное выражение, рассматриваемое как функция с тремя (C, T, E) аргументами, где C — условие, T — результат при C = истина, E — результат при C = ложь. Простой пример различения двух значений в зависимости от бита: если (B_manualtransmission, 6,4). Пример для вложенных if: if(B_manualtransmission, if(B_4wheel, 8,6),4) | Любой | Логический | Любой | Любой |
| le | 2 | Меньше либо равно | Логический | Числовой | Числовой | |
| lt | 2 | Меньше чем | Логический | Числовой | Числовой | |
| max | 2/с динамической длиной | Максимум из разных значений | Числовой | Числовой | Числовой | Числовой |
| min | 2/с динамической длиной | Минимум из разных значений | Числовой | Числовой | Числовой | Числовой |
| max_value | 1 или 1 + 2*n (n обозначает размер метки) | Оценивает максимальное значение поля. Первый операнд — это имя метки. Если последующие операнды не указаны, оценивается общий максимум. Если имеется n пар дополнительных операндов, каждая пара указывает диапазон для одной оси, сообщая первый и последний индексы, которые необходимо учитывать для вычисления максимального значения | Числовой | Переменный | Числовой | Числовой |
| min_value | 1 или 1 + 2*n (n обозначает размер метки) | Оценивает минимальное значение поля. Первый операнд — это имя метки. Если последующие операнды не указаны, оценивается общий минимум. Если имеется n пар дополнительных операндов, каждая пара указывает диапазон для одной оси, сообщая первый и последний индексы, которые необходимо учитывать для вычисления минимального значения | Числовой | Переменный | Числовой | Числовой |
| mul | 2/с динамической длиной | Умножение | Числовой | Числовой | Числовой | Числовой |
| neq e | 2 | Не равно. Два значения разных типов всегда не равны | Логический | Любой | Любой | - |
| nop | 0/с динамической длиной | Операция отсутствует | Любой | Любой | - | - |
| not | 1 | Логическое «не» | Логический | Логический | - | - |
| note f | 2 | Цель оператора Note — предоставить простую возможность объяснить последующие условия коротким словесным выражением. Соответственно, первый аргумент является текстовой строкой, второй аргумент является вычислением, сформулированным в ABSTRACT-SYNTAX (см. 7.4.2) | Любой | Строковый | Любой | - |
| or | 2/с динамической длиной | Логическое «или» | Логический | Логический | Логический | Логический |
| pow | 2 | Степень числа, экспоненциальная функция, pow(a, b) = a b | Числовой | Числовой | Числовой | - |
| previous <g> | 1 | Доступ к ранее рассчитанному значению переменной, например: - previous(B_state); - previous(temp) | Числовой | Переменный | - | - |
| shift_left | 2 | Сдвиг влево (заполнение 0) | Числовой | Числовой | Числовой | - |
| shift_right | 2 | Сдвиг вправо (заполнение 0) | Числовой | Числовой | Числовой | - |
| sqrt | 1 | Квадратный корень числа, \sqrt{x} | Числовой | Числовой | - | - |
| sub | 2 | Вычитание | Числовой | Числовой | Числовой | - |
| value | 1 + n (n обозначает размер метки) | Оператор значения оценивает значение поля, указав имя поля в качестве первого параметра и «значение оси» для каждого измерения поля в качестве следующих параметров. Поле может быть любой формы/размера, например, кривая, карта, индексная таблица. Поле определяется произвольным количеством опорных точек для каждого измерения: - при доступе к элементу поля через индекс поддерживающие точки представляют значения индекса, например, значение (KnockLevel, CylNo); - доступ к элементу поля путем выбора ближайшей нижней опорной точки без интерполяции; - доступ к элементу поля путем вычисления результата с помощью (линейной) интерполяции | Числовой | Переменный | Числовой | Числовой |
| within | 2/3 | Within(A, B): определяет диапазон Within(X, A, B) — истина, если значение X находится в диапазоне A — B, в противном случае — ложь | Логический | Числовой | Числовой | Числовой |
| xor | 2 | Исключительная дизъюнкция, также называемая «эксклюзивной ИЛИ» | Логический | Логический | Логический | Логический |
| a Тип первого параметра определяет тип результата. b Оператор for_time устарел: вместо него должен использоваться оператор duration of. c Это означает, что логическое значение и числовое значение всегда не равны. d Идентичные типы второго и третьего параметров определяют тип результата. e Сравнение логического и числового значений не допускается. f Тип второго параметра определяет тип результата. <g> Тип первого параметра определяет тип результата. | ||||||
ЦИФРОВОЕ ПРИЛОЖЕНИЕ СЛОВАРЯ ВЫБОРА FXD
B.1 Документы словаря выбора FXD
FXD XML-схема доступна в виде электронного приложения к настоящему стандарту.
Для удобства пользования стандартом следующие пункты включают эти документы.
B.1.2 FXD-Selection-Dictionary V.1.1.0.xsd
<xs:schema xmlns:xs=«http://www.w3.org/2001/XMLSchema» xmlns:xml=«http://
www.w3.org/XML/1998/namespace» elementFormDefault=«qualified»
attributeFormDefault=«unqualified»>
<xs:import namespace=«http://www.w3.org/XML/1998/namespace» schemaLocation=«xml.
xsd»/>
<xs:complexType name=«ADMIN-DATA»>
xs:sequence
<xs:element name=«DOC-REVISIONS» type=«DOC-REVISIONS»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«DOC-REVISION»>
xs:sequence
<xs:element name=«REVISION-LABEL» type=«xs:string» minOccurs=«0»/>
<xs:element name=«STATE» type=«STATE»/>
<xs:element name=«DATE» type=«xs:dateTime»/>
<xs:element name=«MODIFICATIONS» type=«MODIFICATIONS» minOccurs=«0»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«DOC-REVISIONS»>
xs:sequence
<xs:element name=«DOC-REVISION» type=«DOC-REVISION»
maxOccurs=«unbounded»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«EXTERNAL-DOC»>
xs:simpleContent
<xs:extension base=«xs:string»>
<xs:attribute name=«HREF» type=«xs:anyURI» use=«required»/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name=«EXTERNAL-DOCS»>
xs:sequence
<xs:element name=«EXTERNAL-DOC» type=«EXTERNAL-DOC»
maxOccurs=«unbounded»/>
</xs:sequence>
</xs:complexType>
<xs:attributeGroup name=«ID-ATTRIBUTE»>
<xs:attribute name=«ID» type=«xs:ID» use=«required»/>
</xs:attributeGroup>
<xs:simpleType name=«STATE»>
<xs:restriction base=«xs:string»>
<xs:enumeration value=«DRAFT»/>
<xs:enumeration value=«RELEASED»/>
<xs:enumeration value=«DEPRECATED»/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name=«LINK»>
xs:annotation
xs:documentationGeneric reference to another element in the schema
instance document.</xs:documentation>
</xs:annotation>
<xs:attributeGroup ref=«LINK-ATTR»/>
</xs:complexType>
<xs:attributeGroup name=«LINK-ATTR»>
<xs:attribute name=«ID-REF» type=«xs:IDREF» use=«required»/>
</xs:attributeGroup>
<xs:complexType name=«MODIFICATION» abstract=«false»>
<xs:sequence>
<xs:element name="CHANGE" type="xs:string"/>
<xs:element name="REASON" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="MODIFICATIONS"><br>
<xs:sequence><br>
<xs:element name="MODIFICATION" type="MODIFICATION"<br>
maxOccurs=«unbounded»/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=«SELECTION»>
xs:sequence
<xs:element name=«SHORT-NAME» type=«SHORT-NAME»/>
<xs:element name=«VT» type=«xs:string»/>
<xs:element name=«DESC» type=«xs:string» minOccurs=«0»/>
<xs:element name=«STATE» type=«STATE»/>
</xs:sequence>
</xs:complexType>
<xs:elementname=«SELECTION-DICTIONARY» type=«SELECTION-DICTIONARY»/>
<xs:complexType name=«SELECTION-DICTIONARY»>
xs:sequence
<xs:element name=«SELECTION-LISTS» type=«SELECTION-LISTS»/>
</xs:sequence>
<xs:attribute name=«VERSION» type=«VERSION» use=«required»/>
</xs:complexType>
<xs:complexType name=«SELECTION-GROUP»>
xs:sequence
<xs:element name=«SHORT-NAME» type=«SHORT-NAME»/>
<xs:element name="VT" type="xs:string"/>
<xs:element name="DESC" type="xs:string" minOccurs="0"/>
<xs:element name="SELECTION-SNREFS" type="SELECTION-SNREFS"
minOccurs=«0»/> <xs:element name=«SELECTION-GROUPS» type=«SELECTION-GROUPS» minOccurs=«0»/> </xs:sequence> </xs:complexType> <xs:complexType name=«SELECTION-GROUPS»> xs:sequence <xs:element name=«SELECTION-GROUP» type=«SELECTION-GROUP» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«SELECTION-LIST»> xs:sequence <xs:element name=«SHORT-NAME» type=«SHORT-NAME»/> <xs:element name=«ADMIN-DATA» type=«ADMIN-DATA»/> <xs:element name=«SELECTIONS» type=«SELECTIONS»/> <xs:element name=«SELECTION-GROUPS» type=«SELECTION-GROUPS»/> </xs:sequence> </xs:complexType> <xs:complexType name=«SELECTION-LISTS»> xs:sequence <xs:element name=«SELECTION-LIST» type=«SELECTION-LIST» maxOccurs=«unbounded»> xs:annotation xs:documentationThe list of selectable values.</ xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name=«SELECTION-SNREFS»> xs:sequence <xs:element name=«SELECTION-SNREF» type=«SNREF» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«SELECTIONS»> xs:sequence <xs:element name=«SELECTION» type=«SELECTION» minOccurs=«0» maxOccurs=«unbounded»/> </xs:sequence> </xs:complexType> <xs:complexType name=«SHORT-NAME»> xs:simpleContent <xs:extension base=«SHORT-NAME-TEXT»/> </xs:simpleContent> </xs:complexType> <xs:simpleType name=«SHORT-NAME-TEXT»> <xs:restriction base=«xs:string»> <xs:pattern value=«[a-zA-Z0-9_]{1,128}»/> </xs:restriction> </xs:simpleType> <xs:complexType name=«SNREF»> <xs:attribute name=«SHORT-NAME» type=«SHORT-NAME-TEXT» use=«required»/>
</xs:complexType><br>
<xs:simpleType name="VERSION"><br>
<xs:restriction base="xs:string"><br>
<xs:enumeration value="1.1.0"/><br>
</xs:restriction><br>
</xs:simpleType><br>
</xs:schema>
B.1.3 FXD-Selection-Dictionary V1.2.0.xml
<SELECTION-DICTIONARYxmlns:xsi=«http://www.w3.org/2001/XMLSchema-instance»
xsi:noNamespaceSchemaLocation=«FXD-Selection-Dictionary_V1.1.0.xsd» VERSION=«1.2.0»>
<DOC-REVISIONS><br>
<DOC-REVISION><br>
<REVISION-LABEL>1.1.0</REVISION-LABEL><br>
<STATE>RELEASED</STATE><br>
<DATE>2016-05-13T10:39:56+02:00</DATE><br>
<MODIFICATIONS><br>
<MODIFICATION><br>
<CHANGE>First version<br>
->ISO MainDocument 8.6.7
<VT>OTHER</VT><br>
<STATE>RELEASED</STATE><br>
</SELECTION><br>
<SELECTION><br>
<SHORT-NAME>FXD_SL_MC_0001/SHORT-NAME><br>
<VT>Accelerator Pedal Position (APP) Sensor</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0281</SHORT-NAME>
<VT>Accelerator Pedal Position (APP) Sensor 1</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0002</SHORT-NAME>
<VT>Accelerator Pedal Position (APP) Sensor 1 and 2</VT><br>
<STATE>RELEASED</STATE><br>
</SELECTION><br>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0003</SHORT-NAME>
<VT>Accelerator Pedal Position (APP) Sensor 2</VT>
<STATE>RELEASED</STATE>
**</SELECTION>**<br>
**<SELECTION>**<br>
**<SHORT-NAME>FXD_SL_MC_0282</SHORT-NAME>**
<VT>Active Grille Air Shutter</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0283</SHORT-NAME>
<VT>Active Lambda Diagnosis</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0284</SHORT-NAME>
<VT>Air Conditioning (A/C) Compressor Control</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0285</SHORT-NAME>
<VT>Air Conditioning (A/C) Compressor Relay</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0286</SHORT-NAME>
<VT>Air Conditioning (A/C) Compressor Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0004</SHORT-NAME>
<VT>Airbag</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0287</SHORT-NAME>
<VT>Airbag Control Module</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0005</SHORT-NAME>
<VT>Ambient Air Temperature (AAT) Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0288</SHORT-NAME>
<VT>Autoignition</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0006</SHORT-NAME>
<VT>Barometric Pressure (BARO) Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0007</SHORT-NAME>
<VT>Battery Energy Control Module (BECM)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0008</SHORT-NAME>
<VT>Battery Module</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0289</SHORT-NAME>
<VT>Battery Voltage</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0009</SHORT-NAME>
<VT>Boost Pressure</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0010</SHORT-NAME>
<VT>Boost Pressure Control</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0011/SHORT-NAME>
<VT>Brake Booster Pressure Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0012</SHORT-NAME>
<VT>Brake Light Switch</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0013</SHORT-NAME>
<VT>Brake Pedal Position (BPP) Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0014</SHORT-NAME>
<VT>Brake Vacuum Pump</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0015</SHORT-NAME>
<VT>Camshaft Position (CMP) Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0016</SHORT-NAME>
<VT>Camshaft Position (CMP) Sensor 2</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0017</SHORT-NAME>
<VT>Camshaft Position (CMP) Sensor 3</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0018</SHORT-NAME>
<VT>Camshaft Position (CMP) Sensor 4</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0019</SHORT-NAME>
<VT>Camshaft Position (CMP) Sensor Inlet</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0021</SHORT-NAME>
<VT>Camshaft Position (CMP) Sensor Inlet 2</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0020</SHORT-NAME>
<VT>Camshaft Position (CMP) Sensor Outlet</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0022</SHORT-NAME>
<VT>Camshaft Position (CMP) Sensor Outlet 2</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0023</SHORT-NAME>
<VT>Camshaft Position/Crankshaft Position (CMP/CKP) Sensor Inlet</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0024</SHORT-NAME>
<VT>Camshaft Position/Crankshaft Position (CMP/CKP) Sensor Outlet</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0290</SHORT-NAME>
<VT>CAN: Brake System Control Module (BSCM)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0291</SHORT-NAME>
<VT>CAN: Hybrid</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0025</SHORT-NAME>
<VT>CAN: Instrument Panel Cluster (IPC)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0292</SHORT-NAME>
<VT>CAN: Master/Slave</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0026</SHORT-NAME>
<VT>CAN: Powertrain</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0293</SHORT-NAME>
<VT>Catalyst System</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0027</SHORT-NAME>
<VT>Charge Air Cooler (CAC)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0294</SHORT-NAME>
<VT>Charge Air Cooler (CAC) Coolant Pump</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0295</SHORT-NAME>
<VT>Charge Air Cooler (CAC) Coolant Temperature Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0028</SHORT-NAME>
<VT>Charge Air Cooler Temperature (CACT) Sensor</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0029</SHORT-NAME>
<VT>Charge Air Cooler Temperature (CACT) Sensor 2</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0296</SHORT-NAME>
<VT>Cold Start Detection</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0445</SHORT-NAME>
<VT>Cold Start Fuel Injector</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0030</SHORT-NAME>
<VT>Cold Start Strategy</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0297</SHORT-NAME>
<VT>COM: Active Grille Air Shutter</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0298</SHORT-NAME>
<VT>COM: Active Grille Air Shutter 2</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0299</SHORT-NAME>
<VT>COM: Airbag Control Module</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0300</SHORT-NAME>
<VT>COM: All Wheel Drive Control Module (AWDCM)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0031</SHORT-NAME>
<VT>COM: Ambient Air Temperature (AAT) Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0301</SHORT-NAME>
<VT>COM: Barometric Pressure (BARO) Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0302</SHORT-NAME>
<VT>COM: Battery Charger Control Module (BCCM)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0032</SHORT-NAME>
<VT>COM: Battery Energy Control Module (BECM)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0033</SHORT-NAME>
<VT>COM: Body Control Module (BCM)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0303</SHORT-NAME>
<VT>COM: Body Control Module (BCM) 1</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0304</SHORT-NAME>
<VT>COM: Body Control Module (BCM) 2</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0034</SHORT-NAME>
<VT>COM: Brake Booster Pressure Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0035</SHORT-NAME>
<VT>COM: Brake Pressure Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0036</SHORT-NAME>
<VT>COM: Brake System Control Module (BSCM)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0037</SHORT-NAME>
<VT>COM: Climate Control (CC)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0038</SHORT-NAME>
<VT>COM: Clutch Control Module</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0039</SHORT-NAME>
<VT>COM: Device Driver</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0305</SHORT-NAME>
<VT>COM: Door Control Module</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0040</SHORT-NAME>
<VT>COM: Drive Motor Control Module (DMCM)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0603</SHORT-NAME>
<VT>COM: Electric Vacuum Pump</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0306</SHORT-NAME>
<VT>COM: Electronic Brake Boost Control Module (EBBC)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0601</SHORT-NAME>
<VT>COM: Electronic Power Steering Control</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0041</SHORT-NAME>
<VT>COM: Engine Coolant Temperature (ECT Sensor @ Cylinder Head)</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0307</SHORT-NAME>
<VT>COM: Engine Hood</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0042</SHORT-NAME>
<VT>COM: Engine Hood Switch</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0308</SHORT-NAME>
<VT>COM: Exhaust Gas Recirculation (EGR) Actuator</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0309</SHORT-NAME>
<VT>COM: Exhaust Gas Recirculation (EGR) Actuator 2</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0310</SHORT-NAME>
<VT>COM: Exhaust Gas Temperature (EGT) Sensor upstream Turbocharger (TC)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0311</SHORT-NAME>
<VT>COM: Front Radar System</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0312</SHORT-NAME>
<VT>COM: Fuel Filler Door</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0602</SHORT-NAME>
<VT>COM: Fuel Fired Passenger Compartment Heater</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0313</SHORT-NAME>
<VT>COM: Fuel Heating Module</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0043</SHORT-NAME>
<VT>COM: Fuel Level (FL) Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0314</SHORT-NAME>
<VT>COM: Fuel Level (FL) Sensor 1</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0044</SHORT-NAME>
<VT>COM: Fuel Level (FL) Sensor 2</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0315</SHORT-NAME>
<VT>COM: Fuel Level (FL) Sensor 3</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0316</SHORT-NAME>
<VT>COM: Fuel Level (FL) Sensor 4</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0045</SHORT-NAME>
<VT>COM: Fuel Pump (FP)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0317</SHORT-NAME>
<VT>COM: Fuel Pump Control Module (FPCM)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0318</SHORT-NAME>
<VT>COM: Fuel System</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0046</SHORT-NAME>
<VT>COM: Gateway</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0319</SHORT-NAME>
<VT>COM: Glow Plug Control Module (GPCM)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0320</SHORT-NAME>
<VT>COM: Glow Plug Control Module (GPCM) 1 and 2</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0321</SHORT-NAME>
<VT>COM: Glow Plug Control Module (GPCM) 2</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0047</SHORT-NAME>
<VT>COM: Glow Plug Indicator</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0322</SHORT-NAME>
<VT>COM: Hybrid Battery Pack Sensor Module</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0048</SHORT-NAME>
<VT>COM: Instrument Panel Cluster (IPC)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0323</SHORT-NAME>
<VT>COM: Ion Current System (ICS)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0324</SHORT-NAME>
<VT>COM: Level Control System</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0325</SHORT-NAME>
<VT>COM: Longitudinal Acceleration Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0049</SHORT-NAME>
<VT>COM: Master/Slave</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0326</SHORT-NAME>
<VT>COM: Nitrogen Oxides (NOX) Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0327</SHORT-NAME>
<VT>COM: Nitrogen Oxides (NOX) Sensor 2</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0328</SHORT-NAME>
<VT>COM: Non-Methane Hydrocarbon (NMHC) Catalyst Heater Control Module</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0050</SHORT-NAME>
<VT>COM: NOx Sensor</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0051</SHORT-NAME>
<VT>COM: Particulate Matter Sensor (PMS)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0329</SHORT-NAME>
<VT>COM: Power Steering Control (PSC) Module</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0330</SHORT-NAME>
<VT>COM: Refueling Button</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0331</SHORT-NAME>
<VT>COM: Selective Catalytic Reduction (SCR) Control Module</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0332</SHORT-NAME>
<VT>COM: Starter Generator Control Module (SGCM)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0333</SHORT-NAME>
<VT>COM: Supplementary Coolant Pump</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0334</SHORT-NAME>
<VT>COM: Thermal Management Control Module</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0052</SHORT-NAME>
<VT>COM: Torque Converter Clutch (TCC)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0053</SHORT-NAME>
<VT>COM: Transmission Control Module (TCM)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0054</SHORT-NAME>
<VT>COM: Transmission Control Module (TCM) Hybrid</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0335</SHORT-NAME>
<VT>COM: Turbocharger (TC) Compressor Actuator</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0336</SHORT-NAME>
<VT>COM: Turbocharger (TC) Control Module</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0055</SHORT-NAME>
<VT>COM: Vehicle Speed</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0056</SHORT-NAME>
<VT>COM: Vehicle Speed Sensor (VSS)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0446</SHORT-NAME>
<VT>Compressed Natural Gas (CNG) Fuel Injector</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0337</SHORT-NAME>
<VT>Compressed Natural Gas (CNG) Fuel Pressure Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0338</SHORT-NAME>
<VT>Compressed Natural Gas (CNG) Fuel Rail Pressure (FRP) Control</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0339</SHORT-NAME>
<VT>Compressed Natural Gas (CNG) Fuel Tank Pressure (FTP) Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0340</SHORT-NAME>
<VT>Compressed Natural Gas (CNG) Fuel Tank System</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0341</SHORT-NAME>
<VT>Compressed Natural Gas (CNG) Fuel Volume Regulator Control</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0342</SHORT-NAME>
<VT>Compressed Natural Gas (CNG) Inertia Fuel Shutoff (IFS) Actuator</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0057</SHORT-NAME>
<VT>Coolant Pump</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0058</SHORT-NAME>
<VT>Coolant Pump (Auxiliary) Relay</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0059</SHORT-NAME>
<VT>Coolant Pump (Auxiliary) Relay 2</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0060</SHORT-NAME>
<VT>Coolant Pump (Low-Temperature Circuit)</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0061</SHORT-NAME>
<VT>Coolant Pump (Supplementary)</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0062</SHORT-NAME>
<VT>Coolant Pump Charge Air Cooler (CAC)</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0063</SHORT-NAME>
<VT>Crankcase Heater</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0064</SHORT-NAME>
<VT>Crankshaft Position (CKP) Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0343</SHORT-NAME>
<VT>Cylinder Deactivation (CD) Actuator Control</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0065</SHORT-NAME>
<VT>Cylinder Pressure Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0066</SHORT-NAME>
<VT>Diesel Particulate Filter (DPF)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0344</SHORT-NAME>
<VT>Diesel Particulate Filter (DPF) 2</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0067</SHORT-NAME>
<VT>Diesel Particulate Filter (DPF) Pressure Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0345</SHORT-NAME>
<VT>Diesel Particulate Filter (DPF) Pressure Sensor 1 and 2</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0346</SHORT-NAME>
<VT>Diesel Particulate Filter (DPF) Pressure Sensor downstream hose line</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0347</SHORT-NAME>
<VT>Diesel Particulate Filter (DPF) Pressure Sensor upstream hose line</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0068</SHORT-NAME>
<VT>Direct Ozone Reduction (DOR) Temperature Sensor</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0069</SHORT-NAME>
<VT>Drive Motor Control Module (DMCM)</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0070</SHORT-NAME>
<VT>Drive Motor Coolant Bypass Valve</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0071</SHORT-NAME>
<VT>ECM: RAM</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0348</SHORT-NAME>
<VT>Electric Drive Motor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0349</SHORT-NAME>
<VT>Engine Compartment Temperature Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0350</SHORT-NAME>
<VT>Engine Components Supply Voltage Relay</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0072</SHORT-NAME>
<VT>Engine Control Module (ECM)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0073</SHORT-NAME>
<VT>Engine Control Module (ECM): 5V Supply Voltage</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0074</SHORT-NAME>
<VT>Engine Control Module (ECM): Analog/Digital Converter</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0075</SHORT-NAME>
<VT>Engine Control Module (ECM): Analog/Digital Converter 2</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0351</SHORT-NAME>
<VT>Engine Control Module (ECM): Barometric Pressure (BARO) Sensor</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0352</SHORT-NAME>
<VT>Engine Control Module (ECM): Battery Supply Voltage</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0353</SHORT-NAME>
<VT>Engine Control Module (ECM): Brake System</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0354</SHORT-NAME>
<VT>Engine Control Module (ECM): Checksum</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0355</SHORT-NAME>
<VT>Engine Control Module (ECM): Coding</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0356</SHORT-NAME>
<VT>Engine Control Module (ECM): Communication</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0076</SHORT-NAME>
<VT>Engine Control Module (ECM): Cylinder Deactivation (CD)</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0357</SHORT-NAME>
<VT>Engine Control Module (ECM): Dual Injection</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0358</SHORT-NAME>
<VT>Engine Control Module (ECM): EEPROM</VT>
<STATE>RELEASED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0078</SHORT-NAME>
<VT>Engine Control Module (ECM): Electronic Throttle Control Module</VT>
<STATE>DEPRECATED</STATE>
</SELECTION>
<SELECTION>
<SHORT-NAME>FXD_SL_MC_0077</SHORT-NAME>
<VT>Engine Control Module (ECM): Electrically Erasable Programmable Read Only
Memory (EEPROM)
<DOC-REVISIONS>
<DOC-REVISION>
<REVISION-LABEL>1.1.0</REVISION-LABEL>
<STATE>RELEASED</STATE>
<DATE>2016-05-13T11:28:23+02:00</DATE>
<MODIFICATIONS>
<MODIFICATION>
<CHANGE>First version
->ISO MainDocument 8.6.11.8
<DOC-REVISIONS>
<DOC-REVISION>
<REVISION-LABEL>1.1.0</REVISION-LABEL>
<STATE>RELEASED</STATE>
<DATE>2016-05-13T11:28:32+02:00</DATE>
<MODIFICATIONS>
<MODIFICATION>
<CHANGE>First version
->ISO MainDocument 8.6.9
<DOC-REVISIONS>
<DOC-REVISION>
<REVISION-LABEL>1.1.0</REVISION-LABEL>
<STATE>RELEASED</STATE>
<DATE>2016-05-13T11:28:39+02:00</DATE>
<MODIFICATIONS>
<MODIFICATION>
<CHANGE>First version
->ISO MainDocument 8.6.11.12.3
<DOC-REVISIONS>
<DOC-REVISION>
<REVISION-LABEL>1.1.0</REVISION-LABEL>
<STATE>RELEASED</STATE>
<DATE>2016-05-13T11:28:47+02:00</DATE>
<MODIFICATIONS>
<MODIFICATION>
<CHANGE>First version
->ISO MainDocument 8.6.10
<DOC-REVISIONS>
<DOC-REVISION>
<REVISION-LABEL>1.1.0</REVISION-LABEL>
<STATE>RELEASED</STATE>
<DATE>2016-05-13T11:28:55+02:00</DATE>
<MODIFICATIONS>
<MODIFICATION>
<CHANGE>First version
->ISO MainDocument 8.6.16
<DOC-REVISIONS>
<DOC-REVISION>
<REVISION-LABEL>1.1.0</REVISION-LABEL>
<STATE>RELEASED</STATE>
<DATE>2016-05-13T11:29:02+02:00</DATE>
<MODIFICATIONS>
<MODIFICATION>
<CHANGE>First version
->ISO MainDocument 8.6.11.16
B.2 Словарь выбора и реестры выбора
Целью словаря выбора является передача текста (словесного) спецификации от ИТС к поставщику ЭБУ.
Реестры выбора объединяются в словарь выбора.
Словарь выбора должен публиковаться только в состоянии «RELEASED». Более ранние записи не должны удаляться, а должны быть переведены в состояние «DEPRECATED» (устаревшее) для сохранения правильных значений в предыдущих контейнерах FXD. Схема словаря выбора определяется в обязательном порядке в файле FXD-Selection-Dictionary_V1.1.0.xsd.
В таблице B.1 определено наименование формы запроса на изменение FXD для новых записей в словаре выбора.
Наименование формы запроса на изменение FXD для новой записи в словаре выбора
B.2.2 Реестр выбора определен для следующих подклассов:
- MON-COMPONENT (см. B.3.2);
- MON-FREQUENCY (см. B.3.3);
- RATIO-GROUP (см. B.3.4);
- MCL-STRATEGY (см. B.3.5);
- READINESS-GROUP (см. B.3.6);
- SIMULATION-METHOD (см. B.3.7);
- GENERIC-TYPE (см. B.3.8).
Элемент «SELECTION-LIST» содержит согласованные отдельные термины («Selections»), которые также могут быть сгруппированы в несколько тем для целей навигации (SELECTION-GROUP).
Шаблон (схема) реестра выбора определяется в обязательном порядке в файле «selection-dictionary.xsd». На рисунке B.1 показана схема элемента SELECTION-LIST.
Рисунок B.1 — Схема элемента SELECTION-LIST
В качестве рабочего языка используют английский язык.
Используемые термины должны основываться на [1], [2], [3] и законодательстве по БД.
Распределение между SHORT-NAME и ITEMS для отдельных терминов («Selections») остается постоянным. Если ИТС желает повторно сопоставить термины с внутренним списком компании, ему необходимо выполнить поиск термина SHORT-NAME в FXD, а затем продолжить переход к списку ссылок.
Соглашения об именах и сокращениях отдельных ITEMS являются обязательными, чтобы идентифицировать все содержимое по SHORT-NAMES и сделать возможным их распределение для создателя в любое время.
Правило создания заголовка SHORT-NAMES для текста спецификации в отдельном SELECTION LIST определяется следующим образом:
Содержание данных в реестре выбора указывают две или три буквы.
SHORT-NAMES для SELECTION ITEMS, которые определены как обязательные, перечислены в соответствующих главах SELECTION LIST.
С помощью элемента SELECTION-GROUP можно сгруппировать отдельные спецификации в разделе SELECTION в соответствии с их тематической областью.
B.3.2 Реестр выбора MON-COMPONENT
Реестр выбора MON-COMPONENT позволяет сделать выбор с целью определения, для какого компонента или системы выполняется описание.
SHORT-NAME в данном случае обеспечивает основу для идентификации и начинается с «FXD_». Имя реестра выбора начинается с SL_MC_ и содержит последовательный четырехзначный номер. В реестре выбора для компонента мониторинга указывается определенное SHORT-NAME, имя компонента или системы и статус.
Определенный формат: FXD_SL_MC_nnnn.
В таблице B.2 приведен пример для датчика положения педали акселератора (APP) MON-COMPONENT 1.
Пример для датчика положения педали акселератора (APP) MON-COMPONENT 1
| SHORT-NAME | VT | STATE |
|---|---|---|
| FXD_SL_MS_0001 | Accelerator Pedal Position (APP) Sensor (датчик положения педали акселератора) | RELEASED |
B.3.3 Реестр выбора MON-FREQUENCY
Реестр выбора MON-FREQUENCY позволяет сделать выбор с целью определения частоты запуска монитора.
SHORT-NAME в данном случае начинается с «FXD_». Имя реестра выбора начинается с SL_MF_ и содержит последовательную трехзначную нумерацию. В реестре выбора для MON-FREQUENCY указывается определенное SHORT-NAME, вид мониторинга и статус.
В таблице B.3 определен пример для MON-FREQUENCY (Continuous).
Пример для MON-FREQUENCY (Continuous)
| SHORT-NAME | VT | STATE |
|---|---|---|
| FXD_SL_MF_001 | Continuous (продолжающийся) | RELEASED |
B.3.4 Реестр выбора RATIO-GROUP
Реестр выбора RATIO-GROUP позволяет сделать выбор для определения группы отношений, которую можно назначить для симптома.
SHORT-NAME в данном случае начинается с «FXD_». Название реестра выбора начинается с SL_RAG_ и содержит последовательную трехзначную нумерацию.
В реестре выбора для RATIO-GROUP указывается определенное SHORT-NAME, имя группы отношений и статус.
Определенный формат: FXD_SL_RAG_nnn.
В таблице B.4 определен пример для PM RATIO-GROUP.
Определение примера для PM RATIO-GROUP
| SHORT-NAME | VT | STATE |
|---|---|---|
| FXD_SL_RAG_014 | PM | RELEASED |
B.3.5 Реестр выбора MCL-STRATEGY
Реестр выбора MCL-STRATEGY позволяет сделать выбор для определения категории законодательства на основе [9].
SHORT-NAME в данном случае начинается с «FXD_». Название реестра выбора начинается с SL_MCL_ и содержит последовательную трехзначную нумерацию.
В реестре выбора для MCL-STRATEGY указывается определенное SHORT-NAME, имя группы отношений и статус.
Определенный формат: FXD_SL_MCL_nnn.
В таблице B.5 приведен пример для верхнего входного значения MCL-STRATEGY вне диапазона.
Пример для верхнего входного значения MCL-STRATEGY вне диапазона (Input Out-Of-Range High)
| SHORT-NAME | VT | STATE |
|---|---|---|
| FXD_SL_MCL_001 | Input Out-Of-Range High (верхнее входное значение вне диапазона) | RELEASED |
B.3.6 Реестр выбора READINESS_GROUP
Реестр выбора RATIO-GROUP позволяет сделать выбор для определения, какая группа готовности может быть назначена для симптома.
SHORT-NAME в данном случае начинается с «FXD_». Название реестра выбора начинается с SL_REG_ и содержит последовательную трехзначную нумерацию.
В реестре выбора для RATIO-GROUP указывается определенное SHORT-NAME, имя группы отношений и статус.
Определенный формат: FXD_SL_REG_nnn.
В таблице B.6 приведен пример для мониторинга катализатора READINESS-GROUP.
Пример для мониторинга катализатора READINESS-GROUP
| SHORT-NAME | VT | STATE |
|---|---|---|
| FXD_SL_REG_003 | Catalyst monitoring (мониторинг катализатора) | RELEASED |
B.3.7 Реестр выбора SIMULATION-METHOD
Реестр выбора SIMULATION-METHOD позволяет сделать выбор для определения, какой метод должен использоваться для запуска симптома отказа.
SHORT-NAME в данном случае начинается с «FXD_». Название реестра выбора начинается с SL_SM_ и содержит последовательную трехзначную нумерацию.
В реестре выбора для SIMULATION-METHOD указывается определенное SHORT-NAME, название метода моделирования и статус.
Определенный формат: FXD_SL_SM_nnn.
В таблице B.7 приведен пример для SIMULATION-METHOD удаления компонента.
Пример для SIMULATION-METHOD удаления компонента
| SHORT-NAME | VT | STATE |
|---|---|---|
| FXD_SL_SM_001 | remove component (удаление компонента) | RELEASED |
B.3.8 Реестр выбора GENERIC-TYPE
Реестр выбора GENERIC-TYPE позволяет сделать выбор для определения, какой тип диагностики должен быть связан с обнаружением отказа.
SHORT-NAME в данном случае начинается с «FXD_». Название реестра выбора начинается с SL_GT_ и содержит последовательную трехзначную нумерацию.
В реестре выбора для GENERIC-TYPE указывается определенное SHORT-NAME, имя универсального типа и статус.
Определенный формат: FXD_SL_GT_nnn.
В таблице B.8 приведен пример для коммуникаций GENERIC-TYPE.
Пример для коммуникаций GENERIC-TYPE
| SHORT-NAME | VT | STATE |
|---|---|---|
| FXD_SL_GT_001 | COMMUNICATION (коммуникации) | RELEASED |
ЦИФРОВОЕ ПРИЛОЖЕНИЕ НАБОРА ПРАВИЛ FXD
C.1 Расшифровка символов и обозначений структуры таблицы
- предупреждение: отрицательные примеры, которые не должны использоваться;
- правильное, желательное представление.
Рисунок C.1 — Идентификационные символы в таблицах
1 — идентификационный символ, является ли пример
отрицательным или положительным; 2 — указание отдельных
ссылок для
; 3 — тип указывает, какой стиль
представления был выбран для псевдокодов; в соответствии
со схемой FXD, информация может быть представлена
с использованием имени данных [DATA-NAME], отображаемого
имени [DISPLAY-NAME], длинного имени [LONG-NAME],
отображения текста [TEXT-MAP] или описания [DESC]; если тип
не указан, псевдокод представляется как имя данных
[DATA-NAME]; 4 — в поле псевдокода перечислены примеры
абстрактного синтаксиса [ABSTRACT-SYNTAX]; необходимо
учесть, что содержание приведенных выше примеров не может
претендовать на полноту, и примеры не обязательно отражают
реальную последовательность симптомов; 5 — указание
рассматриваемой части описания симптомов, например,
разрешающие условия [ENABLE-CONDITIONS] или критерий
обнаружения отказов [FAULT-DETECTION-CRITERIA];
6 — пояснения к отдельным ссылкам в 
Рисунок C.2 — Пример структуры таблицы с идентификационными символами
Примечание — Имя перед квадратными скобками является общим термином. Термин в квадратных скобках показывает точное написание имени элемента.
В таблице C.1 приведены определения терминов.
Для составления описаний FXD на основе симптомов требуются разные типы информации. Они делятся на следующие категории:
- C.3 - основные правила FXD. Данная категория показывает элементарные правила FXD;
- C.4 - правила подготовки данных. Данная категория показывает правила, предписывающие тип информации, который должен быть представлен;
- C.5 - правила представления. Данная категория показывает, как информация должна быть представлена.
В следующих пунктах представлен общий обзор отказов:
- C.3.2 - описание основ;
- C.3.3 - описания на основе симптомов;
- C.3.4 - область описания симптомов;
- C.3.5 - определение разрешающих условий и критериев обнаружения отказов;
- C.3.6 - напряжение аккумулятора и состояние клемм;
- C.3.7 - темы, которые не следует описывать;
- C.3.8 - правила абстракции.
Описывается только путь, который приводит к обнаружению или устранению отказа.
Здесь должны быть перечислены все условия, критерии и параметры, которые необходимы для разрешения или оценки монитора.
Начальная точка для обнаружения отказа:
- для всех описаний можно предположить, что компонент (система) явно (однозначно и постоянно) неисправен;
- затем описание должно быть ограничено для представления «Что делает ПО для обнаружения отказа?».
Начальная точка для устранения отказа:
- для всех описаний можно предположить, что компонент (система) явно (однозначно и постоянно) исправен;
- затем описание должно быть ограничено для представления «Что делает ПО для устранения отказа?».
C.3.3 Описания на основе симптомов
Структура XML-схемы в контейнере FXD основана на симптомах. Поэтому все описания должны быть специфическими для симптомов. Это означает, что описания различных симптомов, которые могут быть «связаны», должны четко отличаться друг от друга.
C.3.3.2 Пример содержания описания
В таблице C.2 приведен отрицательный пример содержания описания.
Отрицательный пример содержания описания
C.3.4 Область описания симптомов
Все частичные функции, спецификации стратегии (например, частичная нагрузка, полная нагрузка), варианты переключения между различными пороговыми значениями (например, с помощью кодового слова, битовых масок) и т.п., которые могут быть выбраны с помощью калибровки, должны быть в целом описаны.
Должна быть обеспечена возможность обнаружения и устранения фактического отказа посредством тестирования с использованием всех этих условий/параметров.
Также с помощью этого правила должны быть определены те условия/критерии/параметры, которые не должны документироваться в соответствии с правилами FXD, описанными в следующих разделах.
C.3.5 Определение разрешающих условий и критериев обнаружения отказов
Должно быть сделано четкое различие между разрешающими условиями [ENABLE-CONDITIONS] и критериями обнаружения отказов [FAULT-DETECTION-CRITERIA] (см. рисунок C.2).
Примечание — Имена разрешающих условий или критериев обнаружения отказов перед квадратными скобками — это общие термины. Термин в квадратных скобках показывает точное написание имени элемента.
C.3.5.2 Примеры разрешающих условий и критериев обнаружения отказов
На рисунке C.3 показана иллюстрация ПО.
В таблице C.3 приведен положительный пример разделения разрешающих условий и критериев обнаружения отказов.
В таблице C.4 приведен отрицательный пример идентичных разрешающих условий и критериев обнаружения отказов.
C.3.6 Напряжение аккумулятора и состояние клемм
Если монитор включен, в зависимости от таких параметров, как напряжение батареи и состояние клемм, эта информация должна быть указана.
C.3.6.2 Примеры напряжения батареи/зажигания
В таблице C.5 приведен положительный пример напряжения батареи/зажигания.
В таблице C.6 приведен положительный пример напряжения батареи/зажигания «на время».
В таблице C.7 приведен положительный пример опоздания зажигания.
C.3.7 Темы, которые не следует описывать
C.3.7.1.1 Эксплуатационная готовность ЭБУ
Требуется постоянная эксплуатационная готовность ЭБУ, участвующих в обнаружении/устранении отказов. Поэтому нет необходимости перечислять все условия, необходимые для активности ЭБУ. Как правило, она включает в себя активность главного реле. Также для ЭБУ могут быть специфичны другие условия.
Все условия, необходимые для активации тестовых калибровок и коротких замыканий, указывать не нужно.
C.3.7.2 Пример эксплуатационной готовности ЭБУ
В таблице C.8 приведен отрицательный пример эксплуатационной готовности ЭБУ.
Сложные программные реализации должны быть описаны в упрощенном виде. Однако принцип физического мониторинга, на котором основано ПО, должен быть включен в описание:
- фильтры сглаживания сигнала, другие фильтры и тому подобное не нужно описывать так подробно, как в ПО;
- если для обработанного сигнала/переменной имеется точное значение измерения, его следует использовать;
- если точное измеренное значение для обработанного сигнала/переменной отсутствует, факты должны быть устно описаны в абстрактном синтаксисе [ABSTRACT-SYNTAX] путем указания текстовой строки (например, «Отфильтрованная частота вращения двигателя»).
C.3.8.2 Правило абстракции для VARIABLE-DESCRIPTION
В случае сложных алгоритмов ПО автор FXD может принять решение об упрощении описания даже за пределами приведенных выше правил.
В этом случае необходимо предоставить дополнительный комментарий с использованием элемента DESC, чтобы проинформировать читателя об упрощении.
Рекомендуемый текст для этой информации: «Дополнительная информация предоставляется по запросу».
C.3.8.3 Примеры правила абстракции
В таблице C.9 приведен положительный пример правила абстракции.
В таблице C.10 приведен отрицательный пример правила абстракции.
Отрицательный пример правила абстракции
C.3.9 Работа с мониторами силового каскада
При последующем описании работы с мониторами силового каскада предполагается, что силовой каскад интегрирован в ЭБУ, которые находятся в центре описания FXD, т.е. поставщик ЭБУ имеет подробные знания о конфигурации программного и аппаратного обеспечения установленных компонентов силового каскада.
Для управления приводами, работающими в качестве силового каскада, используются интеллектуальные компоненты силового каскада. Эти интеллектуальные компоненты силового каскада независимо выполняют роль мониторов OBDI (замыкание на батарею, замыкание на массу, разомкнутая цепь) и передают результат мониторинга на центральный процессор (CPU) ЭБУ через шину данных в ЭБУ.
Пороговые значения мониторинга зависят от следующих аппаратных критериев:
- используемый тип силового каскада (для пороговых значений на основе напряжения);
- используемый тип силового каскада и конкретного контакта для подключения силового каскада (для пороговых значений на основе тока).
Требования к описанию мониторов силового каскада такие же, как и для всех других мониторов.
Кроме того, должны быть рассмотрены следующие требования к описанию.
В отношении разрешающих условий:
- если требуется с технической точки зрения, необходимо указать состояние актуатора (вкл/выкл) (для разграничения между мониторами включенного и выключенного состояния силовых каскадов);
- если актуатор управляется с использованием технологии сигналов с широтно-импульсной модуляцией (ШИМ), необходимо указать диапазоны сигналов ШИМ, в пределах которых способен работать соответствующий монитор;
- если для работы мониторов используются так называемые «диагностические импульсные генераторы», это должно быть указано.
В отношении критериев обнаружения отказов:
- если имеются калибруемые метки применения для пороговых значений отказа, они всегда должны указываться.
Если поставщик и OEM согласились принять во внимание конкретные аппаратные конфигурации проекта, необходимо также следующее:
- индикация пороговых значений конкретного отказа (значения для напряжения/значения для тока);
- индикация конкретного типа силового каскада (как примечание в критериях обнаружения отказов).
В таблице C.11 приведены положительные примеры описания мониторинга силового каскада.
Положительные примеры описания мониторинга силового каскада
C.3.10 Работа с интеллектуальными модулями
В данном контексте термин «интеллектуальные модули» относится ко всем компонентам, которые выполняют несколько автоматических мониторов и передают соответствующие результаты мониторинга на ЭБУ, который находится в фокусе описания FXD, через шину связи или дискретные цифровые соединения (например, технология связи SENT).
Обычно интеллектуальные модули можно разделить на следующие группы ЭБУ:
Пример — Датчик NOx, датчик твердых частиц;
Интеллектуальные модули не обязательно должны быть подключены к ЭБУ, который находится в фокусе описания FXD, через прямой канал связи, т.е. вложенная связь возможна и распространена.
На рисунке C.3 представлен пример связи.
ИКН — система избирательной каталитической нейтрализации отработавших газов
Рисунок C.3 — Взаимодействие интеллектуальных модулей с ЭБУ
В связи с тем, что поставщик блока управления, который находится в центре внимания описаний FXD, обычно не имеет доступа или имеет ограниченный доступ к информации мониторов, которые работают в подключенных интеллектуальных модулях, возможно только ограниченное описание FXD этих мониторов.
Для соответствующего обозначения данных описаний атрибут XML PARTIAL должен быть настроен активным для всех описаний FXD для мониторов интеллектуальными модулями.
Минимальные требования к объему описаний FXD для мониторов интеллектуальными модулями:
- описание всех операций по устранению отказов, которые происходят в ЭБУ, который находится в центре внимания описаний FXD;
- описание всех операций интерпретации отказов, которые происходят в ЭБУ, находящемся в центре внимания описаний FXD;
- обозначение этого типа описания с использованием XML-атрибута PARTIAL (DESC-EXTENT).
В таблице C.12 приведен положительный пример описания мониторинга SENT.
В таблице C.13 приведен положительный пример описания подключенного внешнего ЭБУ.
- C.4.4 - определенный подход к подготовке данных;
- C.4.5 - «симметрия» диагностических симптомов;
- C.4.6 - работа с ингибированием, исключением и валидацией;
- C.4.7 - разграничение разрешающих условий;
- C.4.8 - заполнение обязательных и необязательных элементов.
C.4.1 Информация, воспринимаемая человеком
Информация, воспринимаемая человеком, относится к терминам «длинное имя» [LONG-NAME], «отображение текста» [TEXT-MAP] и «описание» [DESC].
Ожидается, что этой функции будет присвоено четкое и информативное длинное имя [LONG-NAME] во время разработки ПО.
Если длинное имя [LONG-NAME] не является информативным с технической точки зрения, для пояснения должно быть предоставлено информативное описание данных с использованием функции отображения текста [TEXT-MAP].
Кроме того, дополнительный текст и/или дополнительная информация, касающаяся формулы, может быть предоставлена с использованием описания [DESC].
C.4.1.2 Примеры информативного длинного имени, отображения текста, имени и описания данных
В таблице C.14 приведен положительный пример информативного длинного имени.
Положительный пример информативного длинного имени
![]() | Ссылка | Тип | Псевдокод |
| Условия разрешения | ... AND Bit_1 == 0.0 AND | ||
| 1 | ftl_can >= enable_threshold_value_1 | ||
| Ссылка | 1 | Длинное имя для ftl_can: уровень в топливном баке | |
В таблице C.15 приведен отрицательный пример длинного имени и отображения текста.
В таблице C.16 приведен положительный пример имени данных и описания.
Положительный пример имени данных и описания
Следует избегать сокращений, которые не соответствуют стандарту SAE (например, сокращения, применяемые только внутри компании). Если эти сокращения используются, то они должны быть объяснены. Например, это можно сделать, используя отображение текста функций FXD [TEXT-MAP] или описание [DESC].
Аббревиатура «TDC» (Верхняя мертвая точка).
В таблице C.17 приведен положительный пример сокращения.
Положительный пример сокращения
В таблице C.18 приведен отрицательный пример сокращения.
Отрицательный пример сокращения
Цель заметки — предоставить простую возможность объяснить последующие условия коротким словесным выражением. Кроме того, заметки должны быть информативными и интерпретируемыми.
Описания всегда должны соответствовать последующим описаниям.
C.4.3.2 Пример несоответствующей заметки
В таблице C.19 приведен пример несоответствующей заметки.
C.4.4 Определенный подход к подготовке данных
При представлении ПО подход заключается в том, чтобы, когда это возможно, отрицательные этапы ПО были проиллюстрированы в позитивном ключе. Кроме того, доступное ПО должно быть соответственно абстрагировано.
Примечание — Не следует описывать условия прерывания/остановки (например, сброс триггера не требуется, если только этот сброс не представляет собой автономное состояние).
На рисунке C.4 показан положительный пример описания с положительной логикой.
Рисунок C.4 — Положительный пример описания
с положительной логикой
На рисунке C.5 показан отрицательный пример точного описания в соответствии с ПО.
Рисунок C.5 — Отрицательный пример точного описания в соответствии с ПО
C.4.5 «Симметрия» диагностических симптомов
Как правило, диагностический монитор является «симметричным», если симптом отказа соответствует следующим критериям:
- идентичные разрешающие условия для проверки наличия и отсутствия назначенной ошибки,
- для обнаружения исправного состояния, полностью противоположного (логическое отрицание) критерию обнаружения отказа (например, отказ обнаруживается, если var_1 > threshold_1, а исправное состояние обнаруживается при var_1 <= threshold_1),
- идентичные условия подтверждения для ошибки и исправного состояния.
Далее перечислены правила описания, относящиеся к симметрии монитора.
C.4.5.2 Описание разрешающих условий
Если физические разрешающие условия идентичны для обнаружения отказов и для обнаружения исправного состояния, элемент ENABLE-CONDITIONS должен быть заполнен, а элемент OK-ENABLE-CONDITIONS должен быть создан без содержимого, но атрибут xsi:nil установлен в «true».
Оба элемента должны быть заполнены полностью (т.е. в обоих элементах должны содержаться общие части).
C.4.5.3 Описание критерия обнаружения
Если критерий обнаружения отказа является полной противоположностью (логическое отрицание) критериям обнаружения исправного состояния, элемент FAULT-DETECTION-CRITERIA должен быть заполнен, а элемент OK-DETECTION должен быть создан без содержимого, но атрибут xsi:nil установлен в «true».
Оба элемента должны быть заполнены полностью (т.е. в обоих элементах должны содержаться общие части).
C.4.5.4 Описание подтверждения отказа
Если подтверждение идентично подтверждению отказа, элемент FAULT-DEBOUNCE должен быть заполнен, а элемент OK-DEBOUNCE должен быть создан без содержимого, но для атрибута xsi:nil установлено значение «true».
Оба элемента должны быть заполнены полностью (т.е. в обоих элементах должны содержаться общие части).
Ниже приведены примеры описания асимметричной и симметричной диагностики.
В таблице C.20 приведен положительный пример описания асимметричной диагностики.
В таблице C.21 приведен положительный пример описания симметричной диагностики.
Положительный пример описания симметричной диагностики
В таблице C.22 приведен положительный пример описания частично асимметричной диагностики.
Положительный пример описания частично асимметричной диагностики
В таблице C.23 приведен отрицательный пример описания частично асимметричной диагностики.
C.4.6 Работа с ингибированием, исключением и валидацией
C.4.6.1 Ингибирование. Общая информация
Ингибирование реализуется программным алгоритмом для запрещения выделенной функциональности ПО. В контексте диагностики/БД запрещенные функции являются функциями мониторинга.
Информация относительно ингибирования не предоставляется в разрешающих условиях (/FAULT-SYMPTOM-EXCH-DESC/FAULT-SYMPTOMS/FAULT-SYMPTOM/FAULT-DETECTIONS/FAULT-DETECTION/ENABLE-CONDITIONS), она предоставляется только в рамках ингибирования (/FAULT-SYMPTOM-EXCH-DESC/FAULT-SYMPTOMS/FAULT-SYMPTOM/INHIBITIONS). Это сделано намеренно, поскольку ингибирование представляет собой особый механизм запрещения функциональности ПО.
C.4.6.2 Ингибирование с помощью информации, связанной с симптомом отказа
Программная мера для запрещения выделенной функциональности с помощью информации, связанной с симптомом отказа, реализуется программным алгоритмом, который либо использует жестко закодированную информацию о состоянии:
(/FAULT-SYMPTOM-EXCH-DESC/FAULT-SYMPTOMS/FAULT-SYMPTOM/INHIBITIONS/BY-SYMPTOM/FAULT-SYMPTOM-REFS),
(/FAULT-SYMPTOM-EXCH-DESC/FAULT-SYMPTOMS/FAULT-SYMPTOM/INHIBITIONS/BY-SYMPTOM/AUXILIARY-OBJECT-REFS),
либо использует идентификатор функции FID:
(/FAULT-SYMPTOM-EXCH-DESC/FAULT-SYMPTOMS/FAULT-SYMPTOM/INHIBITIONS/BY-SYMPTOM/FID-REFS),
который может быть разрешен или запрещен по симптому отказа и/или информации о состоянии вспомогательного объекта.
Данная информация о состоянии по симптомам отказа и/или вспомогательным объектам может быть откалибрована в зависимости от реализации ПО.
Ингибирование по симптомам отказа с помощью FID-типа «CALCULATION»:
FID-тип «CALCULATION» используется для нормального ингибирования, например, если уже обнаруженный симптом отказа должен препятствовать вводу других зависимых симптомов отказов. В схеме FXD это возможно с помощью «механизма FID» для ингибирования и применения FID-типа «CALCULATION».
Ингибирование по симптомам отказа с помощью FID-типа «VALIDATION»:
запрещение в связи с валидацией используется в случаях, когда ведомый монитор должен ждать, пока успешно не запустится соответствующий главный монитор. В схеме FXD это возможно с помощью «механизма FID» для ингибирования и применения FID-типа «VALIDATION».
Пример — Монитор катализатора ожидает сигнала исправного состояния от датчика кислорода.
C.4.6.3 Ингибирование с помощью исключения
Запрещение с помощью исключения используется всякий раз, когда две функции или два монитора не могут выполняться или могут не выполняться одновременно. Условия запрета с помощью исключения должны быть указаны в соответствующем элементе.
(/FAULT-SYMPTOM-EXCH-DESC/FAULT-SYMPTOMS/FAULT-SYMPTOM/INHIBITION/BY-FUNCTION/EXCLUSIONS/EXCLUSION).
C.4.6.4 Примеры ингибирования, исключения и валидации
В таблице C.24 приведен отрицательный пример ингибирования.
В таблице C.25 приведен отрицательный пример исключения.
Отрицательный пример исключения
В таблице C.26 приведен отрицательный пример валидации.
Отрицательный пример валидации
C.4.7 Разграничение разрешающих условий
Если разрешающие условия являются обширными и/или сложными, последовательно перечислять эти разрешающие условия часто бессмысленно. Это затрудняет или даже делает невозможным интерпретацию временных, параллельных или связанных последовательностей.
Поэтому для упрощения интерпретации разрешающих условий имеет смысл сгруппировать связанные разрешающие условия и дать им информативные заголовки.
- общее разрешающее условие;
- монитор условий входа;
- диапазон измерений;
- начало измерения;
- условия для диапазона измерения;
- конец измерения;
- таймер подтверждения;
- ...
C.4.7.2 Пример дифференциации разрешающих условий
В таблице C.27 приведен положительный пример № 1 дифференциации разрешающих условий.
Положительный пример № 1 дифференциации разрешающих условий
В таблице C.28 приведен положительный пример № 2 дифференциации разрешающих условий.
Положительный пример № 2 дифференциации разрешающих условий
C.4.8 Заполнение обязательных и необязательных элементов
Схема FXD содержит как обязательные, так и необязательные теги. Такое разделение позволяет быстро идентифицировать элементы, которые не были заполнены по ошибке.
- элемент FAULT-DETECTION-CRITERIA:
- если информация не может быть предоставлена, поскольку у симптома нет критериев обнаружения отказов, это должно быть объяснено с помощью свободного текста.
Все остальные обязательные элементы:
- если информация не может быть предоставлена, потому что соответствующий симптом не поддерживает эту функцию, атрибут xsi:nil должен быть установлен в «true».
- как правило, необязательные элементы всегда будут заполнены, если соответствующая функция поддерживается описываемым симптомом.
C.4.8.2 Примеры обязательного поля
В таблице C.29 приведен положительный пример обязательного поля.
В таблице C.30 приведен отрицательный пример обязательного поля.
C.4.9 Условия запрета с использованием системных констант
Условиями запрета можно управлять с помощью нескольких механизмов в ЭБУ, находящемся в центре внимания описания FXD.
Следующая спецификация относится только к управлению условиями запрета с помощью системных констант.
Можно наблюдать следующие константы системы.
Системная константа определяет, существуют или нет функции или частичные функции с условиями запрета в ПО (вариантное управление).
Системная константа сама управляет условием запрета или составляет условие запрета.
Эти системные константы (характеристики 1 и 2) могут использоваться как для категории DISABLE-FULLY, так и для категории DISABLE-REPORT-ONLY.
- в элементе CONFIGURATION должны быть указаны соответствующие системные константы; в элементе DISABLE-FULLY или элементе DISABLE-REPORT-ONLY должны быть указаны условия, которые управляют состоянием запрета через указанную системную константу;
- информация не указывается при отсутствии условий запрета.
- в элементе CONFIGURATION должны быть указаны соответствующие системные константы; в элементе DISABLE-FULLY или элементе DISABLE-REPORT-ONLY должен быть указан специфический для проекта результат оценки состояния системной константы;
- информация не указывается при отсутствии условий запрета.
В таблице C.31 приведен положительный пример условия запрета.
В таблице C.32 приведен положительный пример условия запрета.
В следующих пунктах представлено содержание раздела о представлении информации:
- C.5.2 - системные константы и параметры конфигурации;
- C.5.6 - представление формул;
- C.5.7 - контрольные опции после калибровки;
- C.5.8 - приводы и датчики;
- C.5.9 - функционально равные условия;
- C.5.10 - работа со стратегиями обнаружения отказов;
- C.5.11 - работа с критериями устранения отказов в случае нескольких стратегий;
- C.5.12 - последовательность описания для нескольких записей в отношении нескольких выпусков;
- C.5.13 - порядок описания для функциональных записей;
- C.5.14 - XOR-информация.
C.5.2 Системные константы и параметры конфигурации
Когда описание симптомов мониторинга зависит от системных констант и/или параметров конфигурации, оно должно составляться исключительно для конкретной системной константы и/или настройки параметров конфигурации, которая зафиксирована в программной сборке описательного проекта.
Эти системные константы/параметры конфигурации должны быть соответственно указаны в элементе «CONFIGURATION».
C.5.2.2 Примеры системной константы
В таблице C.33 приведен положительный пример системной константы.
В таблице C.34 приведен отрицательный пример № 1 системной константы.
Отрицательный пример № 1 системной константы
В таблице C.35 приведен отрицательный пример № 2 системной константы.
C.5.3 Биты, состояния и комплексные значения
- в комплексных значениях описываются тщательно рассчитанные или смоделированные значения в случаях, когда физические значения, на которых они основаны, и их содержание не могут быть легко определены.
Если биты, состояния или комплексные значения, используемые в ПО, релевантны для описания, они должны быть сопоставлены с базовыми физическими условиями с использованием элемента ABSTRACT-SYNTAX.
Глубина разрешения зависит от требований OEM и должна быть согласована соответствующим образом.
Исходный, неразрешенный бит, само состояние или комплексное значение должны быть предоставлены с помощью оператора примечания до его разрешения.
1 Если бит, состояние или комплексное значение могут быть преобразованы в дополнительные биты, и/или состояния, и/или комплексные значения, последние также должны быть преобразованы в их физические условия.
2 В некоторых случаях OEM и поставщик документации FXD могут согласиться с тем, что не имеет смысла дополнительно разрешать биты, и/или состояния, и/или сложные значения из-за их физической сложности. В этих случаях эти биты, и/или состояния, и/или комплексные значения должны быть описаны сложным и информативным способом в прозе с использованием описаний [DESC].
Далее приведены примеры комплексного значения и бита с дополнительным описанием и без него.
В таблице C.36 приведен положительный пример комплексного значения.
В таблице C.37 приведен положительный пример бита с дополнительным описанием.
Положительный пример бита с дополнительным описанием
В таблице C.38 приведен отрицательный пример бита без дополнительного описания.
Отрицательный пример бита без дополнительного описания
![]() | Ссылка | Тип | Псевдокод |
| Критерий обнаружения отказа | 1 | DA-NA | Bit_2 [0] == 0.0 |
| 1 | DESC | ||
| Ссылка | 1 | Бит без дополнительного описания | |
На рисунке C.6 показан положительный пример разрешения.
Условные операторы и/или ветвления позволяют реализовать различные стратегии мониторинга и/или спецификации мониторинга посредством калибровки (например, с помощью кодового слова).
Все условные утверждения и/или разветвления, которые могут быть установлены с помощью калибровки и которые влияют на мониторинг описываемого симптома, должны быть описаны полностью.
Условные операторы и/или ветвления всегда должны предоставляться в едином формате с использованием оператора «IF-THEN-ELSE».
C.5.4.2 Примеры условного оператора и ветвления
В таблице C.39 приведен положительный пример условного оператора.
В таблице C.40 приведен положительный пример ветвления.
Битовые маски относятся к конструкциям, в которых отдельные биты байта используются для различных разрешающих условий. Точные условия могут быть «скрыты» за отдельными битами битовой маски.
Битовые маски должны быть представлены в едином, непрерывном, интерпретируемом формате, который можно прочитать с помощью инструмента.
Основная структура должна быть построена с использованием оператора «IF-THEN-ELSE». В пределах этой структуры должны быть предусмотрены различные условия для соответствующей позиции бита.
Метка битовой маски должна указываться оператором «getbit» и битовой позицией, которая отвечает за отдельные условия. Начальное значение приращения (битовая позиция) всегда имеет значение «0».
Оператор «getbit» должен использоваться исключительно с операторами «TRUE» или «FALSE».
Путь THEN всегда должен присваиваться оператору «TRUE», а путь ELSE всегда должен присваиваться оператору «FALSE».
В таблице C.41 приведен положительный пример битовых масок.
Положительный пример битовых масок
В таблице C.42 приведен отрицательный пример битовых масок.
В таблице C.43 приведен отрицательный пример битовых масок с использованием побитового оператора.
![]() | Ссылка | Тип | Псевдокод |
| Разрешающие условия | 1 | ... measurement_value_1 >= enable_threshold_value_1 AND Bitmask_1 & enable_threshold_value_2 == 1.0 OR ... | |
| Ссылка | 1 | Описание с затрудненным пониманием | |
При создании документации обычно используется следующая структура описания:
Пример — Число оборотов двигателя > 2000 об/мин.
Когда структура описания отклоняется от программной реализации, реализованное ПО должно быть абстрагировано таким образом, чтобы для представления могла использоваться типичная структура.
C.5.6.2 Примеры представления формул
В таблице C.44 приведен положительный пример представления формул.
Положительный пример представления формул
В таблице C.45 приведен отрицательный пример представления формул.
C.5.7 Контрольные опции после калибровки
Если описание симптома мониторинга зависит от контрольной опции после калибровки, должны быть перечислены все возможные варианты. Описание всегда должно предоставляться в едином формате в разрешающих условиях [ENABLE-CONDITIONS] и критериях обнаружения отказов [FAULT-DETECTION-CRITERIA].
Контрольная опция после калибровки должна быть представлена с помощью оператора «IF — THEN — ELSE».
Данные контрольные опции после калибровки должны маркироваться с использованием соответствующего длинного имени [LONGNAME], описания [DESC] или примечания.
C.5.7.2 Примеры контрольных опций после калибровки
В таблице C.46 приведен отрицательный пример № 1 опций после калибровки.
![]() | Ссылка | Тип | Псевдокод |
| Конфигурация | 1 | LO-NA | IDX_VAR_EMI system_constant_1 |
| Ссылка | 1 | Контрольная опция после калибровки не должна быть указана в конфигурации | |
В таблице C.47 приведен отрицательный пример № 2 контрольных опций после калибровки.
Можно предположить, что должен быть установлен некий компонент (привод/датчик), подлежащий мониторингу.
По этой причине информация о месте установки не должна предоставляться в качестве критерия разрешения в соответствующем компонентном мониторе.
С другой стороны, всегда должны предоставляться условия, запрашивающие активность компонента, подлежащего мониторингу.
C.5.8.2 Пример приводов и датчиков
В таблице C.48 приведен отрицательный пример, относящийся к приводам и датчикам.
C.5.9 Функционально равные условия
Функционально равные условия (например, избыточные условия, условия, которые исключают друг друга, подмножества и т.п.) не должны предоставляться несколько раз, если одновременное указание этого условия не дает никакой информации для создания сводной таблицы и/или документации по обслуживанию клиентов.
Описания симптомов, которые имеют частоту мониторинга «Один раз за ездовой цикл (DCY)», не нуждаются в дополнительном указании, что монитор не должен работать в этом DCY во включенном состоянии [ENABLE-CONDITION].
C.5.9.2 Примеры разрешающих условий для функционально равных условий
В таблице C.49 приведен отрицательный пример № 1 разрешающих условий для функционально равных условий.
Отрицательный пример № 1 разрешающих условий для функционально равных условий
![]() | Ссылка | Тип | Псевдокод |
| FAULT-DETECTION_1 | |||
| Разрешающие условия | Bit_1 == 1.0 | ||
| 1 | AND | ||
| 1 | measurement_value_engine_speed > enable_threshold_value_1 AND measurement_value_2 > enable_threshold_value_2 | ||
| 2 | AND | ||
| 2 | Bit_engine_stop == 0.0 | ||
| Ссылка | 1 | Приведенное здесь значение является подмножеством условия, указанного в п. 2. | |
| 2 | Это условие всегда выполняется, когда выполняется условие 1. Таким образом, оно является избыточным для условия 1 и может быть опущено | ||
В таблице C.50 приведен отрицательный пример № 2 разрешающих условий для функционально равных условий.
C.5.10 Работа со стратегиями обнаружения отказов
Когда в описываемом ПО есть симптомы, которые имеют несколько стратегий обнаружения отказов [FAULT-DETECTION], различные стратегии обнаружения отказов, включая соответствующую информацию (например, разрешающие условия), должны быть представлены как отдельные записи [FAULT-DETECTION] обнаружения отказов в базе симптомов отказов [FAULT-SYMPTOM-BASE] соответствующего симптома отказа.
В таблице C.51 приведен положительный пример симптома отказа с несколькими стратегиями.
Положительный пример симптома отказа с несколькими стратегиями
В таблице C.52 приведен отрицательный пример симптома отказа с несколькими стратегиями.
Отрицательный пример симптома отказа с несколькими стратегиями
C.5.11 Работа с критериями устранения отказов в случае нескольких стратегий
Для симптомов, которые имеют несколько стратегий, должна быть предоставлена вся информация об этих стратегиях.
Однако при описании критериев обнаружения исправного состояния может иметь место ситуация, когда помимо критериев обнаружения исправного состояния существуют дополнительные критерии, которые применяются ко всем дальнейшим стратегиям. В этом особом случае критерии не должны перечисляться по отдельности, но могут быть представлены с использованием стандартного текста «All other fault detection criteria of this symptom are not fulfilled» («Все остальные критерии обнаружения отказа по этому симптому не выполнены»).
C.5.11.2 Примеры симптомов с несколькими стратегиями
В таблице C.53 приведен положительный пример симптомов с несколькими стратегиями.
Положительный пример симптомов с несколькими стратегиями
В таблице C.54 приведен отрицательный пример симптомов с несколькими стратегиями.
Отрицательный пример симптомов с несколькими стратегиями
C.5.12 Последовательность описания для нескольких записей в отношении нескольких выпусков
Симптом, который является идентичным для нескольких выпусков, должен быть описан одинаково, т.е. все множественные записи должны быть перечислены в одинаковом порядке для всех выпусков (см. таблицу C.55).
В таблице C.55 приведен положительный пример размещения информации для последовательных выпусков.
В таблице C.56 приведен отрицательный пример размещения информации для последовательных выпусков.
C.5.13 Порядок описания для функциональных записей
Могут быть задокументированы несколько функций/версий. Цель заключается в том, чтобы иметь возможность документировать все соответствующие функции/версии для одного симптома отказа, включая другие функции подачи, которые влияют на работу мониторов.
Вначале должна быть указана функция/версия, которая описывает критерии отказа симптома отказа. Она называется основной функцией.
Все остальные функции, называемые функциями подачи, должны быть перечислены позже.
C.5.13.2 Примеры расположения основной функции и функций подачи
В таблице C.57 приведен положительный пример расположения основной функции и функций подачи.
Положительный пример расположения основной функции и функций подачи
![]() | Ссылка | Тип | Псевдокод |
| Функция ЭБУ | 1 | Main function Feeder function Feeder function | |
| Ссылка | 1 | Основная функция всегда должна указываться первой, а функции подачи — последующими | |
В таблице C.58 приведен отрицательный пример расположения основной функции и функций подачи.
Отрицательный пример расположения основной функции и функций подачи
![]() | Ссылка | Тип | Псевдокод |
| Функция ЭБУ | 1 | Feeder function Main function Feeder function | |
| Ссылка | 1 | Функция подачи упомянута первой, но она не должна упоминаться перед основной функцией | |
При разрешении или обнаружении отказа может возникнуть ситуация, когда указанные условия могут быть правильно представлены только с использованием конструкции XOR.
Для четкого и понятного представления XOR-информации должны быть подробно описаны возможности ввода, которые необходимо выполнить.
В таблице C.59 приведен положительный пример представления двух частей XOR-информации.
Процесс должен быть построен таким образом, чтобы все условия ингибирования были известны поставщику и суммировались у него в генераторе FXD для формирования стандартного документа в соответствии с настоящим стандартом.
На рисунке D.1 показано генерирование базового документа.
1 — алгоритм, специфичный для поставщика ПО ЭБУ;
2 — генератор стандартного документа на основе
содержания FXD
Рисунок D.1 — Генерирование базового документа
Описание всегда основано на ингибированном симптоме отказа, показанном на рисунке D.2 как Fault_symptom_B.
D.2 Объяснение структуры ингибирования
Распознанный Fault_symptom_A из diagnostic_function_A ингибирует программный компонент в diagnostic_function_B, обозначенный как FID_B.
Данный контекст определяется с использованием калибруемой матрицы ингибирования и поэтому считается известным ИТС. На рисунке D.2 этот процесс показан позицией 2 и словом «Калибровка».
1 — рассматриваемая Diagnosis_function_B; 2 — калибровка; 3 — вычисление отказа; 4 — мастер проверки диагноза; 5 — валидация отказа; 6 — «жестко закодированный», немашиночитаемый участок цепи ингибирования; 7 — замещающее действие из документации на ПО
Рисунок D.2 — Контекст диагностической функции и описание элементов
Однако эта ссылка представляет собой только первый раздел полной цепочки ингибирования. Компонент ПО, обозначенный как FID_B в diagnostic_function_B, включает в себя вычисление fault_symptom_B, т.е. исследует, присутствует ли отказ Fault_symptom_B в разделе ПО, обозначенный как FID_B. Если FID_B ингибирован (например, потому что присутствует Fault_symptom_A), это означает, что основной Fault_symptom_B не может быть обнаружен. Взаимодействие между FID_B и Fault_symptom_B жестко закодировано в ПО.
На этом цепь ингибирования замыкается, т.е. в конкретном описанном случае активный Fault_symptom_A приведет к тому, что рассматриваемый Fault_symptom_B будет ингибирован или не будет рассчитан.
В рамках описания контейнера данных теперь необходимо, с точки зрения рассматриваемого Fault_symptom_B, описать «жестко закодированный», немашиночитаемый раздел цепочки ингибирования. Данный процесс показан позицией 6 на рисунке D.2.
Данный термин применяют к постоянным ссылкам в программном коде, которые не могут быть изменены приложением. В настоящее время они становятся известными ИТС только после изучения документации ПО. Простое машиночитаемое представление данного контекста является важным требованием для содержимого контейнера FXD. Индивидуальные механизмы ингибирования и подлежащие определению элементы описания показаны на рисунке D.2.
Элемент «Список ингибирующих FID» (List of inhibiting FIDs, см. 7.9.5) содержит список всех FID, относящихся к рассматриваемой диагностической функции и которые могут ингибировать рассматриваемый Fault_symptom_B.
На рисунке D.2 не показаны исключения (см. 7.6.13.2), т.е. общие FID для прикладных и диагностических функций, параллельное выполнение которых с рассматриваемой diagnostic_function_B должно быть исключено. Имена функций, работа которых вызывает задержку обнаружения рассматриваемого Fault_symptom_B, должны быть введены в это поле.
Другим элементом для ингибирования является FID валидации («Validation FID», см. 7.6.13.1). Этот элемент обозначает программные компоненты, которые координируют связь между так называемой главной и ведомой диагностикой. Окончательный вывод отказа из ведомой диагностики происходит только после завершения соответствующей главной диагностики.
Пример — Диагностика каталитического нейтрализатора (ведомая) сообщает только о том, что обнаружен отказ, когда диагностика кислородного датчика (главная) сообщила, что датчик кислорода, необходимый для оценки каталитического нейтрализатора, функционирует. Для более старых диагностических функций все еще может быть возможно, что отдельные симптомы отказов и рассматриваемая функция будут ингибированы ПО напрямую, без ссылки на матрицу ингибирования. Эти контексты должны быть введены в элементе «Описание ингибирования симптомов отказа (жестко закодированное)» (см. 7.6.13.1).
БИБЛИОГРАФИЯ
| УДК 656.13:006.354 | ОКС 35.240.60 |
| Ключевые слова: диагностические данные, обмен данными, отказ, обнаружение, диагностика | |











- разрешающие условия;
- результат (FCM);
- выполнение монитора; DCY — ездовой цикл
- разрешающие условия;
- результат (FCM);
- выполнение монитора; DCY — ездовой цикл
- разрешающие условия;
- результат (FCM);
- выполнение монитора; DCY — ездовой цикл

































































