ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ГОСТР
59891—
2021 (ИСО 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)
Издание официальное
Москва Российский институт стандартизации 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) путем изменения отдельных фраз (слов, ссылок), которые выделены в тексте курсивом. При этом приложения А, В, С, D полностью идентичны.
Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5—2012 (пункт 3.5) и для увязки с наименованиями, принятыми в существующем комплексе национальных стандартов Российской Федерации
5 ВВЕДЕН ВПЕРВЫЕ
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)
© ISO, 2018
© Оформление. ФГБУ «РОТ», 2022
Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии
Содержание
1 Область применения
2 Обозначения и сокращения
3 Информация о версии спецификации
4 Концепция FXD
4.1 Обзорная часть
4.2 Традиционный рабочий процесс
4.3 Необработанные данные
4.4 Формат FXD и пример
4.5 Базовая концепция FXD
4.6 Рабочий процесс FXD
4.7 Пример рабочего процесса FXD
4.8 Ограничения для обновлений схемы
5 Варианты использования FXD
5.1 Основные положения
5.2 Вариант использования 1: Доставка «необработанных данных» поставщиками программного обеспечения электронного блока управления
5.3 Вариант использования 2: Генерация документации на основе необработанных данных FXD
6 Общие свойства элементов FXD
6.1 Атрибуты
6.2 Вариантное кодирование
6.3 Реестры общего выбора
6.4 Ссылки на внешние документы
6.5 Ссылки на переменные ЭБУ и калибровочные метки
6.6 Общие элементы FXD, используемые для идентификации и описания
7 Описание элементов FXD
7.1 Основные положения
7.2 Элемент ADMIN-DATA
7.3 Элемент COMPANY-DATAS
7.4 Элемент DATA-DICTIONARY
7.5 Элемент VARIABLE-DICTIOTIONS
7.6 Элемент FAULT-SYMPTOMS
7.7 Элемент FAULT-SYMPTOM-3RD-PARTYS
7.8 Элемент SERVICE-06-IDS
7.9 Элемент FIDS
7.10 Элемент AUXILIARY-OBJECTS
7.11 Элемент MASKS
7.12 Элемент TEXT-MAPPINGS
7.13 Любая иная информация (для контейнера)
Приложение А (обязательное) Цифровое приложение FXD XML-схемы
Приложение В (обязательное) Цифровое приложение словаря выбора FXD
Приложение С (обязательное) Цифровое приложение набора правил FXD
Приложение D (справочное) Ингибирование симптомов отказа
Библиография
Введение
Цель данного стандарта — определить новый формат описания обмена данными с симптомами отказов (FXD), который был разработан для предоставления машиночитаемых описаний преимущественно алгоритмов симптомов отказов, которые реализуются в виде диагностического программного обеспечения в электронном блоке управления.
Основной сценарий применения формата — передача данных от поставщика функций и программного обеспечения изготовителю транспортного средства в стандартизированном формате (XML-схема FXD), допускающем инструментальную (автоматизированную) обработку.
Поставщик программного обеспечения предоставляет исходные данные, связанные с программным обеспечением, которые должны быть расширены и уточнены изготовителем транспортного средств для различных случаев применения. На основе данных в формате FXD и соответствующих значений калибровки могут быть созданы несколько документов для конечного пользователя, например, «сводная таблица для документации бортовой диагностики».
Основными ожидаемыми преимуществами использования FXD являются повышение общей эффективности обмена данными, а также независимость от обработки форматов, специфичных для поставщика системы и изготовителя транспортного средства.
FXD является расширением ODX для поддержки документирования и обмена данными о симптомах отказов для одобрения типа транспортного средства и информации по ремонту и техническому обслуживанию.
Обязательное приложение включает в себя XML-схему FXD, представляющую модель данных для цифрового обмена данными бортовой диагностики (БД) в формате FXD.
Сложность систем мониторинга БД постоянно возрастает. Технический прогресс и обновления нормативных требований приводят к усложнению как самих систем двигателей, так и соответствующих систем мониторинга БД. Например, с течением времени значительно увеличилось количество мониторов и, следовательно, диагностических кодов отказов (DTC), как описано в настоящем стандарте, для 6-цилиндровых бензиновых двигателей с 2000 г. до 2012 г. (см. рисунок 1).
С увеличением количества мониторов БД возрастает их сложность.
На рисунке 1 показана возрастающая сложность систем БД.
1 — 6-цилиндровый бензиновый двигатель
Рисунок 1 — Возрастающая сложность систем бортовой диагностики
Сложность современных проектов (например, наличие разных вариантов) у изготовителя транспортного средства является важным аспектом при создании диагностической документации. Для всех стратегий мониторинга, связанных с БД, разрабатывается соответствующая документация БД. Когда данные стратегии разрабатываются разными проектными командами, может потребоваться специальная адаптация и калибровка систем БД.
Для разработки качественной документации БД во всех проектах необходимы значительные усилия для синхронизации и ручной настройки. Очевидно, что такой конкретный подход имеет ограниченный потенциал повторного использования.
На рисунке 2 показана сложность проекта по разработке корректной документации БД.
Рисунок 2 — Сложность проекта по разработке корректной документации бортовой диагностики
Кроме того, более сложные бизнес-модели (распределение работы между несколькими компаниями) усложняют процесс документирования БД.
В прошлом, как правило, поставщик электронного блока управления также поставлял большую часть соответствующего программного обеспечения. В настоящее время и в еще большей степени в будущем с внедрением Autosar1) будет усиливаться тенденция к появлению программных пакетов от изготовителя транспортного средства и сторонних поставщиков.
Как следствие, несколько поставщиков предоставляют информацию для создания документации БД в различных форматах, с разной структурой и содержанием данных. Для понимания функционирования систем БД часто необходимо углубляться в детали организации самой документации к программному обеспечению. Поэтому трудоемкость разработки и интеграции документации, связанной с БД, возрастает из-за ручного анализа и настройки. Очевидно, что этот сценарий допускает лишь ограниченное повторное использование.
На рисунке 3 показан возможный процесс распределения работ и согласования документации БД.
Система управления двигателем
(сторонний постащик ПО)
Рисунок 3 — Процесс распределения работ и согласования документации бортовой диагностики
Документация БД
Большой объем работ по синхронизации и ручной настройке
Ограничения планирования при создании документации БД на этапе разработки также представляют собой мотивирующий фактор для внедрения формата FXD. Поскольку масштабы БД становятся все обширнее, документация создается заблаговременно, но последующие изменения БД неизбежно приводят к необходимости многократной доработки документации. Без эффективного управления информацией, касающейся БД, невозможно решать сложные инженерные задачи в современных условиях жестких графиков выполнения работ.
ГОСТ Р 59891—2021 (ИСО 22901-3:2018)
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Автомобильные транспортные средства
ОТКРЫТЫЙ ОБМЕН ДИАГНОСТИЧЕСКИМИ ДАННЫМИ (ODX)
Ч а с т ь 3 Описание обмена данными с симптомами отказов (FXD)
Automobile vehicles. Open diagnostic data exchange (ODX). Part 3. Fault symptom exchange description (FXD)
Дата введения — 2022—04—01
1 Область применения
Настоящий стандарт определяет машиночитаемые описания всех алгоритмов симптомов отказов, которые реализованы в виде диагностического программного обеспечения (ПО) в электронном блоке управления (ЭБУ) транспортных средств (ТС). Основным назначением стандарта является внедрение стандартизированной передачи данных от поставщика функций и ПО к изготовителю ТС (ИТС) с целью обеспечения возможности инструментальной обработки передаваемой информации.
На основе данных в формате FXD и связанных с ними калибровочных значений могут быть сформированы несколько документов для конечного пользователя, таких как «сводная таблица», являющаяся необходимой частью пакета документации для одобрения типа ТС, или «информация по ремонту и техническому обслуживанию» (ИРТО). Ожидаемыми основными преимуществами использования FXD являются общее повышение эффективности обмена данными, а также независимость обработки от формата, специфичного для поставщика и ИТС.
Настоящий стандарт устанавливает правила для обмена информацией о симптомах отказов ЭБУ между поставщиком ПО ЭБУ и ИТС.
Настоящий стандарт определяет:
- содержание описания обмена симптомами отказов (FXD) для каждого симптома отказа;
- XML-структуру описания обмена симптомами отказов (FXD XML-схема);
- поддерживаемый вариант использования для обмена вышеупомянутым описанием.
2 Обозначения и сокращения
В настоящем стандарте использованы обозначения и сокращения, приведенные в [1]—[3], а также следующие сокращения:
а21 — файл описания ASAP2;
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 Обзорная часть
В автомобильной промышленности определены требования к предоставлению информации, связанной с БД, и разработаны соответствующая концепция и формат.
Были сформулированы следующие основные задачи:
а) разработка машиночитаемого формата для автомобильной промышленности:
1) для одного источника описания симптомов отказа при различных случаях использования документации (например, информация об одобрении типа ТС, ИРТО) в разных вариантах проекта;
2) для осуществления обработки данных с использованием самых современных инструментов;
Ь) использование XML в качестве базовой технологии для определения формата (FXD XML-схема); с) повторное использование структурных паттернов в соответствии с [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, приведенных в приложении С.
4.3.2.3 Требования к считывателям описания «необработанных данных»
Информация, представленная в описании «необработанных данных», должна позволять технически квалифицированному персоналу, обладающему общими знаниями о ТС, но не обладающему конкретными знаниями в области диагностики/БД, понимать физический процесс работы монитора.
Требования:
- общие знания двигателя и ТС;
- общие знания по диагностике и БД;
- знание настоящего стандарта (формата FXD).
Поставщик не будет нести никакой ответственности в случае, если эти «необработанные данные» будут переданы другим потребителям (например, сертифицирующему органу, организации по послепродажному или сервисному обслуживанию). Файл FXD, предоставленный поставщиком, не будет содержать значений ссылочных калибровочных меток.
4.4 Формат FXD и пример
Основные задачи для XML-схемы FXD заключаются в удовлетворении требований документации «сводной таблицы БД».
Для обеспечения автоматического процесса публикации из формата FXD в «сводную таблицу БД» вся соответствующая информация должна быть представлена в формате FXD.
Симптом отказа является основным структурным критерием для «сводной таблицы БД». Вся информация, связанная с симптомом отказа, организована под соответствующим узлом внутри схемы FXD, который называется «FAULT-SYMPTOM».
Наиболее сложная информация в «сводной таблице БД» касается вложенных алгоритмических выражений для «MALFUNCTION-CRITERIA» и «ENABLE-CONDITIONS». Не требуется никаких структур управления, известных из языков программирования.
Пример выражения —
Операнды и операторы должны быть помечены отдельно в структуре XML, т. к. оба должны быть подготовлены для специфичной визуализации, например, публикации в разных графах таблицы.
Поскольку данные FXD, предоставляемые поставщиком ПО, будут содержать «необработанные данные», основанные на реализации ПО, необходима концепция уточнения для поддержки различ-них вариантов использования. Поэтому в FXD вводится принцип наследования, т. е. «необработанные данные», связанные с симптомом, могут быть уточнены для конкретного случая использования путем добавления уточненных информационных характеристик к данным FXD. Позже цепочка инструментов будет обрабатывать характеристики, специфичные для конкретного варианта использования.
«Необработанные данные» будут содержать имена, используемые в ПО, для параметров и метки калибровочных данных, например, для граничных значений. Для создания документации БД имена, используемые в ПО, должны быть заменены именами, понятными конечному пользователю, а метки калибровочных данных должны быть заменены соответствующими значениями. Оба механизма замены должны поддерживаться форматом FXD.
В дополнение к описанным выше требованиям при разработке схемы FXD были приняты во внимание следующие требования к содержанию:
- матрица блокировки;
- управление данными FXD на стороне ИТС (например, управление идентификаторами, ссылки на функции и спецификации ПО и т. д.);
- ИРТО (например, языковой атрибут).
На рисунке 4 показана сводная таблица БД в качестве одного из основных мотивов для определения формата FXD.
T_AST>C_T_AST_PORT_DIAG
...OPERATOR="gt" time after engine start > 15|s] Компонент/ система Код отказа Код отказа (текст SAE) Описание стратегии мониторинга Критерий отказа Пороговое значение Вторичные параметры Разрешающие условия Время мониторинга Частота проверок Световой индикатор Датчик положения заслонки впускного коллектора Р2004 Заслонка впускного коллектора в цилиндре 1 заблокирована в открытом положении Проверка закрытого положения заслонки Напряжение сигнала <2,9 В Таймер после запуска двигателя > 15 с 4 с Постоянная 2 DC Рисунок 4 — Сводная таблица БД как один из основных мотивов для определения формата FXD Моделирование алгоритмических выражений является основной частью схемы FXD, поэтому требует детального объяснения. После анализа содержимого сводных таблиц БД для алгоритмических выражений были сформулированы следующие требования: - включить формальное описание вложенных алгоритмических выражений, основанных на программной реализации; - включить формальные выражения (один операнд может быть текстовой строкой), которые не могут полностью соответствовать программной реализации, но необходимы для уменьшения сложности; - включить свободный текст, например, для ИРТО; - включить прямое повторное использование «необработанных данных». Для описания условий, связанных с симптомами отказов, введен элемент COMPUTATION. Он может быть: - формальным выражением (ABSTRACT-SYNTAX); - неформальным описанием (EXPLANATION). ABSTRACT-SYNTAX представляет дерево выражений, узлами которого могут быть: а) оператор (или функция) ОР с его аргументами (операндами) в качестве дочерних узлов (которые могут вновь являться деревом выражений); Ь) переменная COMPU-VAR, которая состоит из ссылки DATA-DECLARATION-REF на переменную ЭБУ, параметр калибровки или системную константу; с) константа COMPU-CONST, которая может представлять собой: 1) числовое значение V; 2) строковую константу VT; 3) логическое значение VB. Смысл оператора ОР определяется его атрибутом OPERATOR. Набор действительных операторов не указывается в самой XML-схеме FXD, а является цифровым приложением А к настоящему стандарту, чтобы обеспечить возможность его расширения без изменения схемы или изменения основного документа. EXPLANATION состоит из неофициального описания DESC, допускающего несколько абзацев и некоторые стандартные возможности XHTML, и необязательного набора ссылок DATA-DECLARATION-REFS на переменную(ые) ЭБУ, параметр(ы) калибровки и системную(ые) константу(ы), которые позволяют декларировать зависимости от данных ЭБУ. На рисунке 5 показаны элементы COMPUTATION и ABSTRACT-SYNTAX как базовые элементы FXD. Рисунок 5 — Элементы COMPUTATION и ABSTRACT-SYNTAX в качестве базовых элементов FXD Варианты использования, указанные в 5.1 (см. рисунок 8), поддерживают возможность добавления в файл FXD специфических для конкретного варианта использования представлений симптомов отказов. Основным вариантом использования является «адаптация» критериев отказа (FAULT-DETECTION-CRITERIA) и вторичных параметров (ENABLE-CONDITIONS) ИТС для соответствия законодательным требованиям для создания документов, связанных с одобрением типа ТС. Другие варианты использования могут быть представлениями симптомов отказов на разных языках или для определенных групп пользователей. Механизм наследования значений используется следующим образом. Для каждого варианта использования может быть создан дополнительный экземпляр симптома отказа («дочерний симптом отказа»), имеющий то же имя (SHORT-NAME), что и у симптома отказа, являющегося «родительским симптомом отказа». Каждый «дочерний симптом отказа» относится только к одному «родительскому симптому отказа». Разрешается ссылаться на базу симптомов отказов, указанную поставщиком, либо на другой существующий «дочерний симптом отказа». Для «дочернего симптома отказа» все подэлементы являются необязательными, чтобы разрешить изменение только отдельных частей информации симптома отказа. Вся информация, не указанная в «дочернем симптоме отказа», будет получена из его родительской иерархии. «Дочерний симптом отказа» не должен определять обнаружение отказа с именем (SHORT-NAME), которое не определено его родителем. «Дочерний симптом отказа» может только переопределить унаследованные обнаружения отказов. Механизм наследования значений применяется к элементам FAULT-SYMPTOM и VARIABLEDESCRIPTION. Эти элементы имеют атрибут 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». Введение машиночитаемого и стандартизированного формата обмена для описания симптомов отказов позволяет усовершенствовать общий рабочий процесс. Различные форматы и шаблоны будут заменены поставщиком ПО ЭБУ настоящим стандартом. Это позволит создать однородную цепочку инструментов и повторно использовать данные FXD. Поставщик ПО ЭБУ предоставит «необработанные данные», т. е. данные, которые основаны на реализации ПО, и эти данные будут уточняться ИТС в зависимости от варианта использования. Для ИТС инструменты могут эффективно поддерживать следующие задачи, чтобы уменьшить ручное взаимодействие: - интеграция данных FXD от разных поставщиков ПО ЭБУ; - уточнение данных FXD для различных случаев использования (одобрение типа ТС, ИРТО); - дополнение данных FXD значениями калибровки; - создание документов конечного пользователя. На рисунке 6 показан возможный рабочий процесс FXD. ,Ф С\1 ИТС Поставщик по ЭБУ Специфический шаблон ИТС ИТС Специфический шаблон л ИТС Заинтересованная сторона Сводные таблицы БД Заинтересованная сторона ИТС 2 Сводные таблицы Разработка по ИТС Редактор FXD Ф ZT О ИТС N Сводные Заинтересованная сторона Рисунок 6 — Возможный рабочий процесс FXD Редактор FXD Ниже показан пример возможного рабочего процесса FXD — выбор в качестве «разрешающего условия» симптома отказа «Заслонка впускного коллектора в цилиндре 1 заблокирована в открытом положении». Необработанные данные или вводятся в редакторе FXD, или извлекаются из существующих систем. Для управления информацией требуется специальный инструмент FXD (специализированное ПО). Необработанные данные основаны на именах, используемых в ПО, которые зависят от поставщика ПО. Для элемента ABSTRACT-SYNTAX реализован набор правил, которые позволяют обеспечить обратную связь о проблемах в алгоритмических выражениях. Кроме того, рекомендуется реализовать такие возможности, как автозаполнение и проверка правильности имен ПО. После того как информация о симптоме отказа заполнена на стороне поставщика ПО ЭБУ, что является итеративным шагом в процессе разработки ПО, появляется возможность создать файл FXD по схеме FXD. Этот файл будет направлен ИТС. После получения информации FXD от поставщика ИТС приступает к интеграции деталей FXD в хранилище FXD. В зависимости от сложности алгоритма симптомов отказа необходимо уточнить описание для различных вариантов использования. Для выбранного примера уточнение не требуется, т. к. это простое разрешающее условие. Кроме того, для параметров ПО необходимо ввести описание для конкретного случая использования. В этом примере для исходного имени T_AST, используемого ПО, вводится описание «Время после запуска двигателя». После завершения шагов интеграции и уточнения информация готова к обработке для формирования документации конечного пользователя. Значение C_T_AST_MIN_PORT_DIAG будет получено из набора значений калибровки. Единица измерения (структурный паттерн, аналогичный используемому в [4]) является частью определения метки FXD. Наконец, процесс рендеринга будет использовать соответствующую информацию для публикации информации «Время после запуска двигателя > 15 с». На рисунке 7 показаны этапы обработки для создания информации сводной таблицы БД. Файл FXD Подготовка к публикации • Преобразование имен: T_AST -> «время после запуска двигателя» • Обработка для автоматического выбора Создание сводной таблицы БД Файл данных Приложение: • калибровка данных приложений: C_T_AST_M I N_PORT. DIAG -> 15 с данных Компонент/ система Код отказа Код отказа (текст SAE) Описание стратегии мониторинга Критерий отказа Пороговое значение Вторичные параметры Разрешающее условие Время отображения Частота проверок Световой индикатор Датчик положения заслонки впускного коллектора Р2004 Заслонка впускного коллектора в цилиндре 1 заблокирована в открытом положении Проверка закрытого положения заслонки Напряжение сигнала <2,9 В Таймер после запуска двигателя > 15с 4 с Постоянная 2 DC Рисунок 7 — Этапы обработки для создания информации сводной таблицы БД Обновление XML-схемы FXD для соответствия новым требованиям может привести к необходимости обновления инструментария с обеих сторон, поставщика и ИТС. Кроме того, поставщикам может потребоваться поэтапное введение в эксплуатацию новых обязательных полей для генерирования новых описаний. Чтобы обеспечить непрерывную работу с последней версией схемы, введен стандартный текст «пусто из-за перехода на новую схему». Поставщики должны использовать стандартный текст «пусто из-за перехода на новую схему» для определения новых обязательных текстовых полей, которые не могут быть заполнены надлежащим описанием. Этот новый стандартный текст должен использоваться только в обязательных текстовых полях. Новые необязательные поля создаваться не должны. На рисунке 8 показан основной поток информации и обзор вариантов использования. Поставщик ПО ЭБУ ИТС Вариант использования 1. Генерация "необработанных данных" поставщиком ПО Вариант использования 2. Генерация документации БД, относящейся к FXD Представление документов законному органу Представление документов организациям-' послепродажного обслуживания Вариант использования 2.1. Сводная таблица БД, основанная на FXD, для официального одобрения типа ТС Вариант использования 2.2. ИРТО, основанная на FXD Рисунок 8 — Основной поток информации и обзор вариантов использования В таблице 1 показан вариант использования 1. Таблица 1 — Вариант использования 1: Доставка «необработанных данных» поставщиками программного обеспечения электронного блока управления Название варианта использования Вариант использования 1: Доставка «необработанных данных» поставщиками ПО ЭБУ Цель Поставка «необработанных данных» из версии ПО ЭБУ поставщиками ПО ЭБУ позволяет генерировать сводную таблицу БД на основе FXD и информацию о симптомах отказов для информации о послепродажном ремонте и обслуживании Действующее лицо Поставщик ПО ЭБУ Входные данные Версия ПО ЭБУ Выходные данные «Необработанные данные» FXD-XML, специфичные для версии ПО ЭБУ Краткое описание «Необработанные данные» о симптомах отказов предоставляются в виде так называемой «базы симптомов отказов». Такое представление симптома отказа может не подходить для разных случаев использования, специфичных для ИТС, поэтому могут быть добавлены дополнительные представления одного и того же симптома отказа. Более подробное описание используемого механизма приведено в 4.5.3 В дополнение к версии программы, поставляемой ИТС, поставщик может доставить соответствующий файл, содержащий согласованное описание симптомов отказа, поддерживаемое соответствующей версией программы. Этот файл будет называться файлом FXD. Любая предоставленная информация должна рассматриваться как необработанные данные. В таблице 2 приведена сводная таблица для варианта использования 2.1 «Генерация сводной таблицы БД для официального одобрения типа ТС». Таблица 2 — Вариант использования 2.1: Генерация сводной таблицы БД для официального одобрения типа ТС Название варианта использования Вариант использования 2.1: Генерация сводной таблицы БД для официального одобрения типа ТС Цель Сгенерировать сводную таблицу БД из файла FXD в качестве документации для одобрения типа ТС Действующее лицо ИТС Входные данные - версия ПО; - версия данных; - «необработанные данные» FXD-XML, специфичные для версии ПО ЭБУ; - информация о запрете отношений между отдельными симптомами; - правовые требования; - другая необходимая информация Выходные данные Сводная таблица БД должна содержать: - имя компонента/системы; - законодательно закрепленный DTC; - код клиента (DTC); - код клиента (текст отказа (неисправности) клиента); - описание стратегии мониторинга; - критерии отказа; - пороговое значение; - вторичные параметры; - разрешающие условия; - подтверждение неисправности; - частота мониторинга; - информирование световым индикатором; ит.д. Краткое описание Информация, представленная в исходных данных, подготавливается в соответствии со спецификациями ИТС с учетом дополнительной входной информации (например, законодательных требований) и преобразуется в вид, понятный для уполномоченного органа. Затем ИТС заменяет метки приложений, использованные в исходных данных, значениями приложений в соответствии с конкретной программой и версией данных описываемого проекта (см. рисунок 11) В таблице 3 указана ИРТО на основе варианта использования 2.2 FXD. Таблица 3 — Вариант использования 2.2: Информация о ремонте и техническом обслуживании на основе FXD Название варианта использования Вариант использования 2.2: ИРТО на основе FXD Цель Генерация ИРТО на основе FXD в составе пакета публикации служебной информации ИТС для ремонта Действующее лицо ИТС Окончание таблицы 3 Входные данные - версия программы; - версия данных; - необработанные данные FXD-XML, специфичные для версии ПО ЭБУ; - информация о запрете отношений между отдельными симптомами; - другая необходимая информация Выходные данные Инструкции по устранению отказов. Сервисный информационный лист должен содержать: - имя компонента/системы; - законодательно закрепленный DTC; - код клиента (DTC); - код клиента (текст отказа (неисправности) клиента); - описание стратегии мониторинга; - OK-DETECTION-CRITERIA; - пороговое значение; - вторичные параметры; - разрешающие условия; - OK-DEBOUNCE; - критерии отказа; - информирование световым индикатором; - замещающая функция; - функция защиты; ит. д. Краткое описание После завершения шагов интеграции и уточнения (см. 4.6) информация готова к обработке для создания документации конечного пользователя. В дополнение к информации об обнаружении отказов, обрабатывается также информация для службы по устранению отказов. Процесс рендеринга будет использовать соответствующую информацию для публикации информации, например, «Время после запуска двигателя > 15 с» Существует два вида атрибутов: - содержание: атрибуты, которые поддерживают оценку содержимого соответствующего элемента FXD; эта информация используется для управления дальнейшей обработкой самой информации FXD; - инфраструктура: атрибуты, которые используются для идентификации внутренней XML-структуры описания FXD. Далее представлены существующие атрибуты. Атрибут DESC-EXTENT определяет полноту соответствующего описания симптома отказа. Определяется для элементов: - FAULT-SYMPTOM; - VARIABLE-DESCRIPTION. В таблице 4 определены поддерживаемые значения атрибута DESC-EXTENT. Таблица 4 — Поддерживаемые значения атрибута DESC-EXTENT Значение Объяснение COMPLETE Для идентификации полного описания PARTIAL Для идентификации неполного описания. Атрибут PARTIAL должен использоваться только в случаях, когда поставщик не несет ответственности за утрату частей описания, например, в случае диагностики, выполняемой интеллектуальным устройством Атрибут DESC-EXTENT необходимо отличать от атрибута DESC-STATE. Атрибут DESC-STATE должен использоваться для идентификации описаний, разработка которых, с точки зрения автора, еще не завершена, и которые не приняли окончательный вид. HREF идентифицирует внешний документ по URI. Если URI не является абсолютным (т. е. он не начинается со схемы), то вначале он устанавливается по базовому URI, определенному в xmkbase, а затем — по URI текущего местоположения документа. Например, HREF=http://www.iso.orQ/iso/iso cataloque/cataloque tc/cataloque detail.htm?csnumber=60264. Определяется для элемента EXTERNAL-DOC. ID предоставляет внутренний XML-идентификатор для связанного элемента, который можно использовать для ссылки на этот элемент (см. 6.1.4). Например, ID= «ID47110815». Определяется для элементов: - 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. Атрибут 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. Атрибут OID используется для инвариантной идентификации элемента FXD, но не для связывания. Любой совместимый с FXD инструмент не должен изменять содержание OID (если оно есть) в течение всего жизненного цикла соответствующего элемента. Любая система, которая предоставляет возможности импорта/экспорта FXD в другом формате, должна обеспечивать поддержание OID в течение цикла импорта/изменения/экспорта. Поставщик несет ответственность за обеспечение уникальности OID. Поэтому рекомендуется использовать универсальные уникальные идентификаторы (UUID), описанные в [5]. Например, OID = «499848a3-d5a2-48d9-bd45-525c99e903b3». Определяется для элементов: - FAULT-SYMPTOM; - VARIABLE-DESCRIPTION. Атрибут OPERATOR указывает конкретный оператор FXD, который будет применен к дочерним элементам текущего элемента. Например, OPERATOR = «duration_of». Определяется для элемента ОР. Набор поддерживаемых значений состоит из всех указанных операторов FXD в соответствии с приложением А. Атрибут SI (семантическая информация) определяет семантическую характеристику связанного элемента. В таблице 5 определены поддерживаемые значения атрибута SL Таблица 5 — Поддерживаемые значения атрибута SI Значение Объяснение RAWINFO Для «нейтрального» описания, полученного от поставщика системы в соответствии с вариантом использования 2 SUMMARY Для «финального» описания, созданного в соответствии с вариантом использования 2.1 SERVICE Для «финального» описания, созданного в соответствии с вариантом использования 2.2 OTHER Для остальных вариантов использования Например, SI = «RAWINFO». Определяется для элементов: - FAULT SYMPTOM; - TEXT-MAPPING; - VARIABLE-SESCRIPTION. Атрибут DESC-STATE указывает завершенность соответствующего элемента. Например, DESC-STATE = «RELEASE». Определяется для элементов: - FAULT-SYMPTOM; - VARIABLE-DESCRIPTION. В таблице 6 определены поддерживаемые значения атрибута DESC-STATE. Таблица 6 — Поддерживаемые значения атрибута DESC-STATE Значение Объяснение INITIAL Для первоначального описания DRAFT Для промежуточного описания RELEASED Для «финального» описания Атрибут TI (текстовый идентификатор) предоставляет внутренний XML-идентификатор для соответствующего текстового элемента, который предназначен для использования при указании альтернативных текстов/формулировок (например, на другом языке). Например, TI = «Т147110816». Определяется для элементов: - DESC; - DISPLAY-NAME; - VT. TI состоит из строки произвольных символов. Атрибут VERSION предоставляет номер текущей версии FXD-схемы в качестве единственного поддерживаемого значения. Таким образом, он определяет структуру и содержание соответствующего файла FXD. Атрибут VERSION состоит из трех чисел «x.y.z»: «х» — будет увеличено в случае несовместимых изменений, «у» — будет увеличено в случае совместимых изменений (например, удалены или добавлены только необязательные элементы), «z» — увеличивается для исправления ошибок. Прежние документы становятся недействительными по отношению к новой версии схемы, поскольку, по меньшей мере, изменился номер версии FXD. Приложения должны рассмотреть эту проблему и решить, принимать документ FXD или не принимать. Например, VERSION = «1.5.0». Определяется для элемента FAULT-SYMPTOM-EXCH-DESC. Указанная версия схемы должна использоваться для проверки файла FXD. Атрибут xmkbase — это рекомендованное W3C средство для определения базовых URI для частей XML-документов. Определяется для элемента FAULT-SYMPTOM-EXCH-DESC. Атрибут xmklang используется для указания естественного языка, на котором задано содержимое связанного элемента. Определяется для элементов: - COMPUTATION; - FAULT-SYMPTOM; - FAULT-SYMPTOM-EXCH-DESC; - TEXT-MAPPING; - VARIABLE-DESCRIPTION. Поддерживаемые значения приведены в httD://www.iso.orQ/iso/home/standards/lanquaqe codes.htm. Атрибут xsknil используется для разрешения пустого содержимого в обязательных элементах. Он разрешен для следующих элементов и имеет следующую семантику: - CUSTOM-KODES/пользовательский код отсутствует; - ENABLE-CONDITIONS/не существует разрешающего условия; - FAULT-DEBOUNCE/не существует подтверждения отказа; - LEGAL-CODE/правовой код не существует; - LEGISLATIONS/законодательные ограничения отсутствуют; - OK-DEBOUNCE/имеет такое же содержание, как FAULT-DEBOUNCE; - OK-DETECTION-CRITERIA/логическая инверсия содержания FAULT-DETECTION-CRITERIA; - OK-ENABLE-CONDITIONS/имеет такое же содержание, как ENABLE-CONDITIONS. Чтобы задействовать этот атрибут, соответствующий элемент должен иметь атрибут nillable2 \ настроенный на значение «истина» в соответствующем определении схемы. Атрибут xsktype должен использоваться для указания правильного типа XML в схеме в случае неясностей. В данном случае необходимо выбрать базовый тип для наследования симптомов отказов и описания переменных с помощью атрибута SI, установленного в RAWINFO. Он определен для следующих элементов со следующими значениями: - FAULT-DETECTION/@xsi:type=«FAULT-DETECTION-BASE»; - FAULT-DETECTIONS/@xsktype=«FAULT-DETECTIONS-BASE»; - FAULT-SYMPTOM/@xsktype=«FAULT-SYMPTOM-BASE»; а также - VARIABLE-DESCRIPTION/@xsi:type=«VARIABLE-DESCRIPTION-BASE». Допускаются следующие типы вариантного кодирования: - в зависимости от значения метки калибровки в ПО активируются разные алгоритмы. Эти условия будут предоставлены как часть COMPUTATIONS (например, на которые ссылается ENABLECONDITIONS) в файле FXD; - в зависимости от значения метки внутренней калибровки функции алгоритмы могут быть активированы или деактивированы. Эти метки описаны в выделенном элементе, подробнее см. DISABLE-REPORT-ONLY (см. 7.6.11.13) и DISABLE-FULLY (см. 7.6.11.14). - для одной версии программы существует несколько наборов калибровочных данных, что означает, что одна калибровочная метка может представлять разные значения для разных наборов данных: файл FXD, предоставленный поставщиком, будет содержать только общие названия калибровочных меток, поэтому этот вариант использования не рассматривается. Для нескольких информационных элементов значения должны быть получены из реестров общего выбора (в соответствии с приложением В): - MON_COMPONENT; - MON_FREQUENCY; - READINESS_GROUP; - RATIO_GROUP; - MCL_STRATEGY (ссылка на законодательство/нормативную базу); - SIMULATION-METHOD; - GENERIC_TYPE. Реестры общего выбора должны иметь номера версий. Ограничения для содержимого реестра выбора: - существующие значения из всех более старых версий должны оставаться в силе; - новые версии не должны применяться к существующим данным. В соответствии с различными приведенными примерами должны поддерживаться пробелы и специальные символы. Таким образом, произвольные строки будут поддерживаться без дополнительной разметки для всех реестров выбора в схеме. Если необходимо, из элементов DESC и RESOURCES допускается ссылаться на произвольное количество внешних документов (например, изображений, сложных описаний), используя необязательную структуру EXTERNAL-DOCS. Для ссылки на переменные ЭБУ или метки калибровки введен элемент DATA-DECLARATION. Элемент DATA-DECLARATION содержит имя переменной или метки калибровки, включая «[...]» для доступа к элементу массива и «.» для доступа к подструктуре, если требуется, например, «DSM.DFC_test». Примечание — В случае вариантов калибровочных меток с кодовым обозначением будет указано только общее название, см. 6.2. Дополнительная информация о метках должна быть получена из файла «а21», если необходимо, например, физические единицы, метки осей кривых и карт. При необходимости можно ссылаться на каждый элемент DATA-DECLARATION, используя DATA-DECLARATION-REF. Это позволяет осуществлять множественные ссылки на один и тот же элемент DATA-DECLARATION для повторного использования. Следующая группа элементов FXD используется для уникальной идентификации основных элементов алгоритма диагностического ПО. В основном это переменные, параметры калибровки и параметры конфигурации (системные константы), симптомы отказов, описания переменных и FID. Группа включает: - SHORT-NAME: обязательный идентификатор в соответствии со спецификацией ASAM HDO SHORT-NAME; - LONG-NAME: необязательный элемент, содержащий воспринимаемое человеком имя в соответствии со спецификацией ASAM HDO LONG-NAME; - DESO: необязательный элемент для получения дополнительной информации. Эта группа элементов указывается как «Element-Id». В 6.2—7.4 описаны элементы схемы FXD, определяющие общую информацию, необходимую, например, для обмена файлами FXD. Элемент ADMIN-DATA моделируется аналогично элементу ODX с тем же именем, но для указания информации, специфичной для проекта (см. 7.2.2—7.2.6), необходимы некоторые расширения. В рамках COMPANY-DATA-REF компания, предоставляющая файл FXD (см. 6.3), указывается атрибутом ID-REF. Необходимо ввести семейство блоков управления, чтобы определить тип блока управления, для которого создаются описания. Этот элемент используется для идентификации проекта. Проект будет указан по имени (NAME) и его версии (SW-BASELINE). Элемент RESOURCES должен использоваться для идентификации специфичных для проекта файлов, которые используются в качестве базы данных для файла FXD: - элемент DATA-DESCRIPTION должен содержать ссылку на ресурс описания данных, например, файл «а2!» (обязательно); - элемент CALIBRATION должен содержать ссылку на набор калибровочных данных (необязательно); - элемент EXTERNAL-DOCS может содержать ссылки на используемые дополнительные файлы. Каждый EXTERNAL-DOC предоставляет текстовое объяснение документа и ссылку на него атрибутом HREF. Элементы DOC-REVISIONS являются подмножеством того же элемента в соответствии с [4]. Данная информация используется для различия разных выпусков файла FXD для одной версии программы. Каждый элемент DOC-REVISIONS состоит из: a) REVISION-LABEL: необязательное текстовое поле для указания версии; b) STATE: обязательный элемент для указания степени завершенности по заранее заданным значениям схемы: 1) DEVELOPMENT (для опытно-конструкторских поставок ИТС); 2) SERIES (для серийных поставок ИТС); 3) RELEASED (для выпущенного ИТС); с) DATE: обязательный элемент для указания даты доставки. В данном элементе указывают информацию обо всех компаниях, ответственных за содержание файла FXD (например, имя, задействованный персонал). Это подмножество того же элемента ODX (см. [4]). Для каждой компании предоставляется один элемент COMPANY-DATA. Элемент COMPANY-DATA состоит из следующих элементов, идентифицирующих компанию и ее участников: - Element-Id (см. 6.6); - TEAM-MEMBERS: необязательный элемент для предоставления информации о членах компании (подробнее см. [4]). Примечание — Поставщики ПО ЭБУ будут предоставлять информацию только о компаниях. Элементы DATA-DECLARATIONS используются для описания внутренних переменных ЭБУ, типов данных калибровки и системных констант. Каждый элемент DATA-DECLARATIONS состоит из: a) Element-Id (см. 6.6); b) DATA/DATA-NAME: обязательный элемент, содержащий имя «а21» DATA-DECLARATION; с) DATA/DATA-TYPE: обязательный элемент для указания типа одним из следующих предопределенных значений схемы: 1) CALIBRATED (для калибровочных данных, подлежащих замене при создании сводных таблиц); 2) CALIBRATION-INFO (данные калибровки, которые используются для информации и не должны заменяться ее значениями); 3) NON-CALIBRATABLE (некалибруемые константы, например, системные константы); 4) ONLINE (переменные); 5) STATE-VALUE (значения переменных конечного автомата); d) DATA/DISPLAY-NAME: необязательный элемент для предоставления DISPLAYJDENTIFIER из файла «а21»; е) DATA/DATA-VALUE: необязательная структура для предоставления логического (VB), числового (V) или текстового (VT) значения вместе с необязательной (см. перечисление а) 7.4.1) физической единицей (через UNIT-REF). Элемент DATA-DECLARATION ссылается на одно или несколько вычислений. Этот список введен для повторного использования DATA-DECLARATIONS. Предварительным условием для DATA-DECLARATIONS является то, что внутренние переменные и данные калибровки уникальны в своем контексте (файл «а21»). Элемент 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: 1000 Важно отметить, что вычисления FXD не обязаны оцениваться. Вполне допустимо определить вычисление, которое будет иметь форму (в псевдокоде): sqrt («некоторая неизвестная функция»). Это связано с тем, что основной целью FXD является описание функций, функциональных отношений, условий и алгоритмов для использования в документации. Тем не менее вычисления FXD должны быть как можно более формальными, чтобы позволить автоматическую обработку. Этот подход имеет несколько существенных преимуществ: - FXD-вычисления могут быть частично оценены. Например, метки калибровки могут быть заменены значениями, а части вычислений (поддеревья абстрактного синтаксиса) могут быть сокращены; - все вычисления могут быть преобразованы так, чтобы заменять переменные или физические единицы. Например, условие V32 >100 км/ч может быть автоматически преобразовано в «текущую скорость» более 62 миль/ч; - могут быть обнаружены несоответствия и циклические зависимости; - FXD-вычисления могут быть дополнительно обработаны, главным образом для визуализации. Данный элемент введен для повторного использования физических единиц. На них ссылается формула вычисления, если это необходимо для постоянных значений. Элемент UNIT-SPEC, включая UNIT-GROUPS, UNITS и PHYSICAL-DIMENSIONS, определяется как подмножество соответствующего элемента (см. [4]). Примечание — Физические единицы измерения переменных и меток калибровки неявны и должны быть получены из файла «а21». Элемент 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 для каждого поддерживаемого STATETRANSITION. Элементы VARIABLE-DESCRIPTIONS подчиняются тому же механизму наследования значений, что и элементы FAULT-SYMPTOM. Для этого есть элемент PARENT-REF (см. 4.5.4). Если VARIABLE-DESCRIPTION наследуется от другого VARIABLE-DESCRIPTION, тип переменной не должен изменяться. Кроме того, полная информация о типе переменной может быть перезаписана только целиком. Ключ описания переменной: уникальное имя, указанное поставщиком, описанное в соответствии с 6.6. Этот элемент содержит ссылку на компанию, предоставляющую VARIABLE-DESCRIPTION. В данном пункте указаны имена и версии ECU-FUNC, которые способствуют вычислению описанной переменной. Каждый ECU-FUNC состоит из двух элементов, описанных ниже. 7.5.4.1 Элемент LONG-NAME Это специфичное для поставщика имя ECU-FUNC в соответствии со спецификацией HDO LONG-NAME, указанной в файле «а21». 7.5.4.2 Элемент VERSION Этот элемент содержит версию ECU-FUNC, заданную в элементе «а21» FUNCTION_VERSION для функции, вычисляющей описанную переменную. Этот элемент содержит ссылки на DATA-DECLARATIONS, представляющие некалибруемые константы («системные константы»), которые влияют на вычисление описанной переменной. Этот элемент содержит ссылку на элемент DATA-DECLARATION, который описывается элементом VARIABLE-DESCRIPTION. Элемент SIMPLE-VARIABLE используется, если переменная (например, байт или даже один бит) представляет одно физическое значение, которое не является состоянием (конечного автомата). Для этого варианта использования вычисление описывается одним элементом COMPUTATION. Если значение переменной не представляет отдельное значение, но отдельные биты или битовые поля представляют независимые значения (т. е. флаги), используется элемент BIT-FIELD-VARIABLE. Элемент BIT-FIELD-VARIABLE состоит из элементов BIT-FIELD, каждый из которых представляет одно физическое значение. BIT-FIELD определяется: - LONG-NAME; - BIT-MASK (целое число без знака); - BIT-FIELD-COMPUTATION, ссылающийся на COMPUTATION. Примечание — BIT-FIELD-COMPUTATION возвращает значение для описываемого битового поля, но оно не будет выровнено в соответствии с положением битового поля. Пример — Если описан один бит, BIT-FIELD-COMPUTATION вернет 0/1 независимо от того, в какой битовой позиции определен соответствующий бит. Если переменная представляет состояния конечного автомата, используется элемент STATEGRAPH. STATE-GRAPH состоит из: - STATES: список поддерживаемых значений состояния переменной, использующий элементы DATA-DECLARATION-REF, ссылающийся на элементы DATA-DECLARATION типа DATA-TYPE ‘STATEVALUE’; - INITIAL-STATE: задает начальное состояние, используя элемент DATA-DECLARATION-REF, ссылающийся на элемент DATA-DECLARATION типа DATA-TYPE ‘STATE-VALUE’; - STATE-TRANSITIONS: состоит из произвольного числа элементов STATE-TRANSITION, определяя: - FROM-STATE (ссылка на DATA-DECLARATION); - ТО-STATE (ссылка на DATA-DECLARATION); - REQUIRED-CONDITION (ссылка на определяющие условия COMPUTATION, которые должны быть выполнены для перехода из одного состояния в другое); - STATE-COMPUTATION: возможность указать вычисление документированных значений состояния из внутренних значений переменной граф состояния, если между двумя битами нет полного соответствия (например, маскирование и сдвиг выделенных битов, в этом случае переменная графа состояния реализована как битовое поле). Примечание — Элементы DATA-DECLARATION-REF в INITIAL-STATE, FROM-STATE, ТО-STATE указываются в элементе STATES. В данном подпункте описываются элементы FXD-схемы, определяющие информацию, специфичную для симптомов отказа. Примечание — Симптомы отказа в версии программы, предоставленной сторонними организациями, будут описаны отдельно (см. 7.7). Ключ описания (на основе симптомов отказа): уникальное имя симптома отказа, указанное поставщиком, описанное в соответствии с 6.6. Примечание — Короткое имя (SHORT-NAME) элемента FAULT-SYMPTOM должно соответствовать элементу FAULT-SYMPTOM-NAME файла «а21». Примеры коротких имен: - DFC_Agre; - PVS-DRIFT. Этот элемент содержит ссылку на компанию, предоставившую FAULT-SYMPTOM. В данном пункте указаны имена и версии ECU-FUNC, которые способствуют обнаружению симптома отказа. Приложение С содержит список функций/версий. 7.6.4.1 Элемент LONG-NAME Данный элемент содержит указанное поставщиком имя ECU-FUNC в соответствии со спецификацией HDO LONG-NAME, указанной в файле «а21». Пример — DSALSU. 7.6.4.2 Элемент VERSION Данный элемент содержит версию ECU-FUNC, указанную в элементе «а21» FUNCTION_VERSION для функции диагностики. Данный элемент содержит ссылки на DATA-DECLARATIONS, представляющие некалибруемые константы («системные константы»), которые влияют на расчет описанного симптома отказа. Кроме того, значение каждой системной константы должно быть указано в соответствующем элементе DATA-VALUE. Более подробная информация содержится в приложении С. 7.6.6.1 Правовой код Код отказа, требуемый законодательством, предоставляется как ссылка на вычисление, которое может быть значением, меткой либо меткой с индексацией, которая может быть задана. В таблице 7 определен FAULT-CODE внешнего испытательного оборудования. Таблица 7 — FAULT-CODE внешнего испытательного оборудования Ссылка на сводную таблицу БД Код отказа БД Формат Реализуется как ссылка на вычисление (COMPUTATION-REF). Элемент может содержать имя метки калибровки либо фактическое значение, введенное в виде десятичного значения 7.6.6.2 Элемент CUSTOM-CODES Специфичный для клиента код предоставляется как ссылка на вычисление, в котором можно указать значение, метку либо метку с индексацией. В дополнение к этому тип CUSTOM-CODE может быть указан для обеспечения различия между разными CUSTOM-CODES. В таблице 8 определен сервисный код отказа. Таблица 8 — Сервисный код отказа Ссылка на сводную таблицу БД Отсутствует Формат Реализуется как ссылка на вычисление (COMPUTATION-REF). Элемент может содержать имя метки калибровки либо фактическое значение, введенное в виде десятичного значения 7.6.6.3 Элемент FAULT-TYPE Каждый симптом отказа может быть поставлен в соответствие коду отказа (DTC), и, кроме того, для соответствующего симптома отказа для удобства технического обслуживания могут быть предусмотрены дополнительные отличительные признаки. Классификация типов отказов приведена в [3]. В таблице 9 определен элемент FAULT-TYPE. Таблица 9 — Определение элемента FAULT-TYPE Ссылка на сводную таблицу БД Отсутствует Формат Реализуется как ссылка на вычисление (COMPUTATION-REF). Элемент может содержать имя метки калибровки либо фактическое значение, введенное в виде шестнадцатеричного значения Данный элемент представляет краткое описание MON-COMPONENT или системы. Пример —Датчик 1 положения педали акселератора. В таблице 10 определены элемент MON-COMPONENT или система. Таблица 10 — Определение элемента MON-COMPONENT или системы Ссылка на сводную таблицу БД Компонент/система Формат Текстовое поле с символами ASCII SELECTION-LIST-NAME MON_COMPONENT Данный элемент состоит из элементов ERR-CLASS или MIL-RELEVANCE и необязательного элемента MIL-DEBOUNCE-GROUP. 7.6.8.1 Элемент ERR-CLASS Этот элемент содержит информацию о связи между предупреждением водителя (MIL, EPCL/SYS и т. д.) и приоритетом. В таблице 11 определен элемент ERR-CLASS. Таблица 11 — Определение элемента ERR-CLASS Ссылка на сводную таблицу БД Свечение светового индикатора Формат Реализуется как ссылка на вычисление (COMPUTATION-REF). Элемент может содержать имя метки калибровки либо фактическое значение, введенное в виде десятичного значения Дополнительная информация Примеры возможных классов отказов: - отказ сервисного оборудования (не относящийся к БД); - отказы, связанные с БД (с приоритетом «Отказ» для диагностического устройства); - отказы, связанные с БД «Мониторинг топливной системы» и «Пропуск зажигания»; - отказы, связанные с БД «Контроль пропуска зажигания» [Световой индикатор + мигающий световой индикатор]; - сервисный отказ (не относящийся к БД) с обнулением сервисного отказа, относящегося к БД (только для сервиса); - отказы, связанные с БД, с обнулением отказа по обслуживанию согласно БД (световой индикатор) 7.6.8.2 Элемент MIL-RELEVANCE Данный элемент содержит информацию о том, должен ли описанный элемент FAULT-SYMPTOM включать световой индикатор БД. В таблице 12 определен отказ элемента MIL-RELEVANCE (относящегося к световому индикатору). Таблица 12 — Отказ элемента MIL-RELEVANCE (светового индикатора) Ссылка на сводную таблицу БД Свечение светового индикатора Формат Реализуется как ссылка на вычисление (COMPUTATION-REF). Элемент может содержать имя метки калибровки либо фактическое значение, введенное как «истина» или «ложь» 7.6.8.3 Элемент MIL-DEBOUNCE-GROUP Если совместное устранение неполадок MIL становится необходимым для нескольких элементов FAULT-SYMPTOMS с FCM, основанной исключительно на элементах FAULT-SYMPTOMS, и, если это было согласовано с омологацией, эти элементы FAULT-SYMPTOMS могут быть назначены одной группе MIL. В таблице 13 определен элемент MIL-DEBOUNCE-GROUP. Таблица 13 — Определение элемента MIL-DEBOUNCE-GROUP Ссылка на сводную таблицу БД Отсутствует Формат Реализуется как ссылка на вычисление (COMPUTATION-REF). Элемент может содержать имя метки калибровки либо фактическое значение, введенное в виде десятичного значения Дополнительная информация Только если группа MIL напрямую жестко закодирована в ПО, эта зависимость должна быть описана как текстовая. Пример описания: «Мониторинг топливной системы в аддитивном и мультипликативном диапазоне: FRAmax представляет симптомы отказов FRAmax, FRAmin, ORAmax, ORAmin» Для элемента FAULT-SYMPTOMS из групп компонентов, которые должны выводиться как IUMPR через службу 0916 в соответствии с законодательством БД, должны быть назначены элементы RATIO-GROUP. Элементы RATIO-GROUP следует вводить из реестра выбора (см. С.3.4). Поддерживаются несколько назначений. В таблице 14 определен элемент RATIO-GROUP. Таблица 14 — Определение элемента RATIO-GROUP Ссылка на сводную таблицу БД Существует Формат Реализуется как ссылка на вычисление (COMPUTATION-REF). Элемент может содержать имя метки калибровки либо фактическое значение, введенное в виде десятичного значения SELECTION-LIST-NAME RATIO_GROUP Дополнительная информация Для всех симптомов отказов из RATIO_GROUP в ЭБУ должно быть рассчитано самое низкое индивидуальное соотношение IUMPR, и связанные с ним значения числителя и знаменателя должны быть выведены через службу 09. Отдельные коэффициенты IUMPR для симптомов отказов, которые не должны выводиться для соответствия законодательству по БД, но которые все еще связаны с IUMPR (например, чисто служебная субдиагностика на кислородном датчике), также могут быть назначены предварительно определенным расширенным группам коэффициентов (без коротких идентификаторов SAE). Однако минимальный индивидуальный коэффициент не рассчитывается. Эти расширенные группы отношений служат исключительно для оценки данных IUMPR по темам Данный элемент используют для документирования распределения элементов FAULT-SYMPTOM в отношении статуса готовности (Сервис 0116, PID 0116) и статуса мониторинга (Сервис 0116, PID 4116). В таблице 15 определен элемент READINESS-GROUP Таблица 15 — Определение элемента READINESS-GROUP Ссылка на сводную таблицу БД Отсутствует Формат Реализуется как ссылка на вычисление (COMPUTATION-REF). Элемент может содержать имя метки калибровки либо фактическое значение — Для каждого соответствующего симптома отказа необходимо ввести соответствующую группу READINESS SELECTION-LIST-NAME READINESS_GROUP 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. Таблица 16 — Определение элемента MON-STRATEGY Ссылка на сводную таблицу БД Описание стратегии мониторинга Формат Текстовое поле с символами ASCII Дополнительная информация Должны использоваться термины, основанные на MCL Для рациональности и функциональных проверок из описания должно быть понятно, как используемая стратегия работает для соответствующего компонента. Недостаточно просто ввести такие термины, как «проверка рациональности». Должны быть использованы такие термины, как: - проверка функционального состояния: заслонка закрыта; - проверка на рациональность: ее невозможно открыть; - измерение OSC по сравнению с OSC пограничного катализатора; - коммуникация по шине CAN со шлюзом и т. д. 7.6.11.4 Элемент FAULT-DETECTION-CRITERIA Данный элемент содержит описание критериев обнаружения отказов, которое определяется следующим образом: - FAULT-DETECTION-CRITERIA— это критерий, который «решает», присутствует отказ или нет. Это решение может быть предварительным в том смысле, что может быть необходима последующая фаза подтверждения для проведения различия между фактическим отказом и его ошибочным обнаружением. Эта подтверждающая фаза обычно называется «подтверждение» (debounce). Каждое условие, которое должно быть выполнено как предварительное условие, чтобы решение могло быть вычислено, не относится к FAULT-DETECTION-CRITERIA. Это разрешающие условия (или условия проверки). Дополнительная информация содержится в приложении С. В таблице 17 определен элемент FAULT-DETECTION-CRITERIA. Таблица 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 определен элемент ENABLECONDITIONS. Определение элемента ENABLE-CONDITIONS: - каждое условие, которое должно быть выполнено как предварительное условие (один раз или во время полного вычисления критерия обнаружения отказа), по которому может быть вычислен критерий обнаружения отказа, является разрешающим условием (или условием проверки); - элементарное разрешающее условие обычно может быть представлено в виде: «Метка пороговое значение»; - отдельные элементарные условия состояния разрешения могут быть объединены другими операторами, такими как «И», «ИЛИ» и т. д. Таблица 18 — Определение элемента ENABLE-CONDITIONS Ссылка на сводную таблицу БД Вторичные параметры/разрешающие условия Формат Реализуется как ссылка на вычисление (COMPUTATION-REF), см. 7.4.2 Окончание таблицы 18 Дополнительная информация Ниже описаны условия, которые должны быть выполнены, чтобы сделать возможным вычисление критерия обнаружения отказа. Следующие условия имеют те же эффекты, что и разрешающие условия, однако они должны быть перечислены в отдельных элементах, поскольку они используются для контроля и фильтрации при последующей обработке документа. Элемент Калибровка Эффекты CENTRALCALIBRATIONINFORMATION (см. 7.6.12) Централизованная Функция мониторинга активна. Управление кодом отказа ингибировано DISABLE-FULLY (см. 7.6.11.14) Децентрализованная Функция мониторинга неактивна DISABLEREPORT-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. Таблица 19 — Определение элемента FAULT-DEBOUNCE Ссылка на сводную таблицу БД Длительность подтверждения отказа Формат Реализуется как ссылка на вычисление (COMPUTATION-REF) Дополнительная информация Поставщик ЭБУ должен представить предложение в структуре XML, описывающее полный метод отладки, которое также может быть интегрировано в контейнер ODX. Это относится к процессу отладки, начинающемуся с выполнения FAULT-DETECTION-CRITERIA. Пример — Подтверждение на основе времени, подтверждение на основе инцидентов и т. д. ИТС будет нести ответственность за упрощение омологационных документов. Для этого описание метода отладки должно использовать только термины, согласованные с официальными лицами по омологации (спецификация в основной сводной таблице из омологации) На рисунке 10 показан расчет продолжительности мониторинга. 1 — установлен дефектный компонент; 2 — начало мониторинга; 3 — отказ выявлен; 4 — отказ выявлен и подтвержден; 5 — обновление: диагностические сервисы, IUMPR, FCM; 6 — максимальный период времени для сохранения отказа в FCM в соответствии с действующим законодательством в области БД; 7 — ожидание/MIL Рисунок 10 — Определение продолжительности мониторинга 7.6.11.8 Элемент MON-FREQUENCY Поставщик предоставляет необработанную информацию в качестве предложения, а ИТС применяет эту информацию, например, для сводных таблиц в соответствии с данными калибровки. Перечень возможных значений предоставляется в соответствии с приложением В. В таблице 20 определен элемент MON-FREQUENCY. Таблица 20 — Определение элемента MON-FREQUENCY Ссылка на сводную таблицу БД Частота проверок Формат Текстовое поле с символами ASCII SELECTION-LIST-NAME MON-FREQUENCY — Определенный термин, введенный поставщиком для сводной таблицы БД в соответствии со спецификацией в основной сводной таблице БД из омологации (см. дополнительную информацию) — Для ИТС требуется дополнительный элемент описания, чтобы ввести важную информацию для обслуживания На функциональном уровне частота мониторинга описывает наиболее частое выполнение диагностической функциональности, например, диагностический монитор, которое поддерживает ПО ЭБУ. На уровне конкретного приложения частота мониторинга описывает фактическое поведение диагностической функциональности этого приложения. Далее термин «монитор» относится к одному конкретному элементу FAULT-DETECTION. Для оценки частоты мониторинга принимаются во внимание все предпосылки, особенно значения, рассчитанные в других функциях, которые используются как часть диагностического монитора. Пример — Диагностический монитор имеет набор параметров, влияющих на частоту мониторинга: - «количество раз, за которое монитор выполняется в одном DCY»; - «время задержки монитора после результата мониторинга». С двумя данными параметрами диагностический монитор может быть настроен на любой мониторинг от непрерывного до однократного. Непрерывный мониторинг (Continuous) «Количество раз, за которое монитор выполняется в одном DCY» = FF (бесконечность), «Время задержки монитора после результата мониторинга» = 0. Одиночный мониторинг (Once) «Количество раз, за которое монитор выполняется в одном DCY» = 1, «Время задержки монитора после результата мониторинга» = FF (бесконечно). Определение Обычно монитор выполняется единожды за срок службы ЭБУ. Это может быть проверка во время изготовления ЭБУ или во время изготовления ТС. Один раз за ездовой цикл (Once per driving cycle) Независимо от того, сколько раз разрешающие условия монитора выполняются во время DCY, монитор запускается только один раз и сообщает решение об успешном прохождении теста или отказе, сохраняя в FCM код отказа только один раз. На рисунке 11 показано, как обрабатывается цикл мониторинга, если он выполняется один раз. --разрешающие условия; ★ - результат (FCM); ■■ - выполнение монитора; DCY- ездовой цикл Рисунок 11 — Определение мониторинга за один ездовой цикл Каждый раз, когда выполняются разрешающие условия монитора, немедленно выполняется диагностический монитор. По истечении времени, необходимого для выполнения диагностического монитора и передачи отчета в FCM, монитор выполняется вновь. На рисунке 12 показано, как обрабатывается цикл мониторинга при непрерывном мониторинге. --разрешающие условия; результат (FCM); |^И - выполнение монитора; DCY-ездовой цикл Рисунок 12 — Определение непрерывного мониторинга Диагностический монитор выполняется более одного раза в DCY. Каждый раз, когда выполняются разрешающие условия, монитор принимает, как минимум, одно решение об отказе или не отказе, а не работает непрерывно. На рисунке 13 показано, как обрабатывается цикл мониторинга, если применяется множественный мониторинг. Рисунок 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. Таблица 21 — Определение элемента 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. Таблица 22 — Определение элемента OK-ENABLE-DETECTION Ссылка на сводную таблицу БД Отсутствует Формат Реализуется как ссылка на вычисление (COMPUTATION-REF), см. 7.4.2 Дополнительная информация Здесь описаны условия, которые должны быть выполнены для разрешения вычисления критерия обнаружения восстановления функциональности 7.6.11.11 Элемент OK-DEBOUNCE Данный элемент используют для краткого описания подтверждения при определении исправного состояния с учетом примененных «параметров программы». Применяемые «параметры программы» отображаются с помощью процесса ссылки, для которого используется значение, метка или метка с текстовым описанием (см. рисунок 10). В таблице 23 определен элемент OK-DEBOUNCE. Таблица 23 — Определение элемента OK-DEBOUNCE Ссылка на сводную таблицу БД Отсутствует Формат Реализуется как ссылка на вычисление (COMPUTATION-REF) 7.6.11.12 Ссылка на законодательство в области БД 7.6.11.12.1 Общие положения Данный элемент необходим для обозначения симптомов отказов, связанных с БД, и для других симптомов будет опущен. Этот элемент содержит ссылку на ту часть законодательства, которая инициировала введение или изменение симптома отказа и будет предоставлена поставщиком. 7.6.11.12.2 Элемент LEGISLATION Ссылка на элемент LEGISLATION должна быть представлена в виде текстового поля с символами ASCII. Содержание текстового поля должно быть номером раздела регламента и его детализацией. Пример — LAWCCR 1968.2 РАЗДЕЛ (е) (11.2.1) (А) Для данного элемента не ожидается никаких обновлений в течение срока службы ПО, однако в случае введения новых функций, которые приведут к другому названию симптома отказа, следует указать новый раздел LEGISLATION. В таблице 24 определена ссылка на LEGISLATION в области БД. Таблица 24 — Определение элемента LEGISLATION Ссылка на сводную таблицу БД MCL Формат Текстовое поле с символами ASCII Дополнительно, необязательный XML-элемент получает имя MCL-STRATEGY Дополнительная информация Данная информация является первым шагом к созданию списка MONITORING REQUIREMENTS, который иллюстрирует связь между компонентом, разделом законодательства и кодом (см. [3]). Присвоение «Названия симптома отказа» коду отказа выполняется ИТС с использованием данных 7.6.11.12.3 Элемент MCL-STRATEGY Данная информация необходима для всех комплексных компонентов, имеющих отношение к БД, и содержит общее описание элемента FAULT-DETECTION-STRATEGY для элемента FAULT-SYMPTOM. Используемая терминология указана в реестре выбора (в соответствии с приложением В). В таблице 25 определен элемент MCL-STRATEGY. Таблица 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. Таблица 26 — Определение элемента 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. Таблица 27 — Определение элемента DISABLE-FULLY Ссылка на сводную таблицу БД Неактивные условия не должны появляться в сводной таблице БД Формат Реализуется как ссылка на вычисление (COMPUTATION-REF). Элемент может содержать имя метки калибровки (абстрактный синтаксис) либо фактическое значение, введенное в виде десятичного значения Дополнительная информация Здесь вводятся условия, которые должны быть выполнены для деактивации расчета диагностического алгоритма, в результате чего ошибки не будут записаны в FCM 7.6.11.15 Информация о БД-сервисе 0616 Для разрешения повторного использования этой информации указываются один или несколько конкретных элементов в списке БД-сервиса службы 0616. Требования к запросу результатов бортового мониторинга для конкретных контролируемых систем приведены в [8]. Подробное описание информации о БД-сервисе 0616 см. в 7.8. Данная информация будет указана только для симптомов отказа, относящихся к БД-сервису 0616. 7.6.11.16 Элемент GENERIC-TYPE Данный элемент содержит информацию, к какому типу диагностики относится симптом отказа. Поддерживаются следующие значения: - COMMUNICATION; - ELECTRICAL; - OTHER DIAGNOSIS. В таблице 28 определен элемент GENERIC-TYPE. Таблица 28 — Определение элемента GENERIC-TYPE Ссылка на сводную таблицу БД Отсутствует Формат Текстовое поле с символами ASCII Атрибут Вариант использования SELECTION-LIST-NAME GENERIC_TYPE Описание поддерживаемых стандартных значений: - COMMUNICATION: симптом отказа обнаруживает ошибку связи между двумя ЭБУ или между одним ЭБУ и интеллектуальным компонентом; - ELECTRICAL: симптом отказа обнаруживает электрические ошибки, которые отслеживаются постоянно или непостоянно; более подробная классификация частоты мониторинга может быть создана с использованием уже существующего элемента MON-FREQUENCY; - OTHER DIAGNOSIS: симптом отказа обнаруживает ошибки, которые не являются электрическими или коммуникационными (ошибками связи). Данный элемент обеспечивает центральные метки калибровки, которые влияют на поведение ПО, связанного с симптомом отказа, и, следовательно, на поведение самого симптома отказа. Центральное средство предоставляется центральным функционалом сервиса (например, диспетчером симптомов отказов) для всех симптомов отказа программы, в отличие от меток калибровки, локально определенных в конкретных функциях ПО. Данные метки центральной калибровки, хотя они и указывают разрешающее условие с логической точки зрения, не должны указываться как часть общих разрешающих условий (см. 7.6.11.5), поскольку они не представляют условия физического включения (т. е. их значение не изменится во время работы ЭБУ) и будут использоваться для управления дальнейшей обработкой документации. Элемент COMPUTATION-REF содержит информацию метки, т. е. имя метки калибровки, тогда как элемент INFO-TYPE содержит информацию о типе информации. Поскольку описанные калибровочные метки будут в основном зависеть от поставщика, значения INFO-TYPE также будут зависеть от поставщика. Следующие характеристики симптомов обычно определяются центральной калибровкой: - активация/деактивация симптомов отказа; - конфигурация/настройка поведения инициализации; - подавление монитора при определенных условиях эксплуатации; - контроль вывода из FCM (главный/подчиненный ЭБУ); - настройки, касающиеся центральных механизмов отладки отказа, и т. п. Если поставщик использует более одной калибровочной этикетки, все они должны быть указаны. В таблице 29 определен элемент CENTRAL-CALIBRATION-INFO. Таблица 29 — Определение элемента CENTRAL-CALIBRATION-INFO Ссылка на сводную таблицу БД Отсутствует Формат Реализуется как ссылка на вычисление (COMPUTATION-REF) вместе с текстовым полем «INFO-TYPE» для получения дополнительной информации о калибровочной метке, на которую есть ссылка в COMPUTATION-REF 7.6.13.1 Элемент INHIBITIONS по симптомам Элемент INHIBITIONS по симптомам содержит список симптомов (FAULT-SYMPTOM-REFS), которые ингибируют вычисление описанного в настоящее время симптома отказа (жестко закодировано), или предоставляет список FID (FID-REFS), причем каждый FID предоставляет список ингибирующих симптомов отказов (FAULT-SYMPTOM-REFS) или ингибирующих вспомогательных объектов (AUXILIARY-OBJECT-REFS). В приложении D содержится дополнительная информация и определен список FID для валидации. В таблице 30 определен список 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. Таблица 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 определено описание ингибирующих симптомов отказа (жестко закодировано). Таблица 32 — Описание ингибирующих симптомов отказа (жестко закодировано) Ссылка на сводную таблицу БД Диаграмма запрещения Формат Список имен симптомов отказов, используемых в контейнере, содержащем элемент 7.6.13.2 Элемент INHIBITIONS по функциям Элемент INHIBITIONS по функциональности содержит информацию, касающуюся временного запрещения вычисления рассматриваемого симптома отказа с помощью элемента EXCLUSION, что означает продолжающееся выполнение из-за другой функциональности. Элемент EXCLUSION может быть описан поставщиком как: - свободный текст для обозначения запрещающих функций; - ссылка на одну или несколько меток калибровки, содержащих один или несколько запрещающих FID. ИТС может подготовить элемент EXCLUSION для использования в сводной таблице в официальной форме. Для реализации этих требований данный элемент предоставляет элемент EXCLUSION путем ссылки на элементы COMPUTATION (см. 7.4.2). Некоторые диагностические функции не могут выполняться одновременно с другими функциями, например, адаптация рабочей смеси и вентиляция топливного бака. Это подавление следует рассматривать так же, как и состояние ингибирования, и соответственно планировать. Должны быть введены все названия симптомов и/или функций, которые находятся в прямом соответствии с рассматриваемым симптомом. Если исключения могут быть определены через приложение, должны быть указаны соответствующие ярлыки приложения. В таблице 33 определен элемент EXCLUSIONS. Таблица 33 — Определение элемента EXCLUSIONS Ссылка на сводную таблицу БД Условия разрешения Формат Текстовое поле с символами ASCII Элемент 1 Один или более ярлыков приложения Элемент 2 Область описания Описание необязательных внутренних функций, которые активируются после сохранения симптома отказа в FCM, должно быть представлено в текстовом формате XHTML. Активация замещающей функции осуществляется через жестко закодированную связь между симптомом и замещающей функцией. Примечание — В данном пункте описаны только те меры, которые активируются функцией/модулем и вызывают запись симптома отказа в FCM (т. е. внутреннюю функцию). В таблице 34 определено описание SUBSTITUTION-FUNCTION (жестко закодировано). Таблица 34 — Описание SUBSTITUTION-FUNCTION (жестко закодировано) Ссылка на сводную таблицу БД Отсутствует Формат Описание в формате XHTML, воспринимаемом человеком Описание необязательных внутренних функций, которые активируются до того, как симптом отказа будет сохранен в FCM, должно быть представлено в текстовом формате XHTML. Примечание — Функция активации PROTECTIVE-FUNCTION не калибруется, а жестко запрограммирована в ПО. Такое поведение обычно нежелательно, но для защиты людей и технического оборудования его не всегда можно избежать по техническим причинам. В таблице 35 определен элемент PROTECTIVE-FUNCTION. Таблица 35 — Определение элемента PROTECTIVE-FUNCTION Ссылка на сводную таблицу БД Отсутствует Формат Описание в формате XHTML, воспринимаемом человеком Данный элемент обеспечивает приблизительную классификацию метода моделирования для запуска симптома отказа, связанного с БД. В таблице 36 определен элемент SIMULATION-METHOD. Таблица 36 — Определение элемента SIMULATION-METHOD Ссылка на сводную таблицу БД Метод моделирования не должен появляться в сводной таблице БД, как описано в реестре выбора. Компетентные органы могут запрашивать более подробную информацию Формат Текстовое поле с символами ASCII Атрибут Вариант использования SELECTION-LIST-NAME SIMULATION_METHOD Поддерживаемые стандартные значения и их семантика (с примерами): - REMOVE COMPONENT: вызвать симптом отказа путем перемещения компонентов. Датчики отсоединены. Отсутствует сажевый фильтр; - MODIFIED COMPONENT: для компонента была разработана специальная электрическая или механическая манипуляция, которая должна иметь те же эффекты, что и реальный отказ. Эффективность сажевого фильтра: механическое разрушение. Эффективность бензинового катализатора: старение с использованием печи; - BREAK OUT BOX: симуляция электрического отказа. Короткое замыкание. Разрыв цепи; - EXTERNAL SIGNAL SIMULATION BOX: для запуска симптома отказа необходимо моделирование входов системы (сигнал датчиков). Датчик 02 с низким быстродействием. Датчик NOx недоступен; - EXTERNAL ACTUATOR DRIVER BOX: чтобы вызвать симптом отказа, требуется имитация выходов (положение привода) через приспособление, искажающее выходной сигнал ЭБУ. Заклинившая в закрытом положении заслонка рециркуляции выхлопных газов. Генерация пропусков зажигания через катушку зажигания; - SOFTWARE CONTROL STRATEGY: для вызова симптома отказа была разработана специальная стратегия управления ПО по моделированию среды. Стратегия должна быть активирована с помощью запроса от внешнего инструмента, приспособление для EXTERNAL ACTUATOR DRIVER BOX не требуется. Пропуск зажигания через запрос от инструмента. Датчик 02 с низким быстродействием; - NOT FEASIBLE при омологации: невозможно продемонстрировать отказ, связанный с симптомом отказа (например, если существует риск серьезного повреждения ТС). Повреждение памяти. Электрический сбой датчика атмосферного давления (когда датчик давления находится внутри ЭБУ и недоступен); - элемент OTHER: для получения дополнительной информации. Цель данного механизма — добавить любое содержание XML с пространством имен, отличным от пространства имен «по-name». Например, ИТС могут перечислить дополнительную собственную информацию о конкретных симптомах (вариант использования 2.2, см. 5.3). В таблице 37 определена стыковочная точка для собственного расширения ИТС. Таблица 37 — Стыковочная точка для собственного расширения ИТС Ссылка на сводную таблицу БД Отсутствует Формат XML Для симптома отказа 3-й стороны доступны следующие элементы: - SHORT-NAME: название симптома отказа, используемое компанией, предоставляющей документ FXD; - THIRD-PARTY/COMPANY-DATA-REF: ссылка на компанию, которая изначально предоставляет сторонние функции по обнаружению отказов; - THIRD-PARTY/FAULT-SYMPTOM-3RD-PARTY-SHORT-NAME: имя симптома отказа, определенное компанией, которая изначально предоставляет сторонние функции по обнаружению отказов. В таблице 38 определен элемент FAULT-SYMPTOM-3RD-PARTY. Таблица 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 для мониторинга катализатора). Таблица 39 — Определение элемента SERVICE-06-IDS Ссылка на сводную таблицу БД Присутствует Формат Дополнительная информация Название метки или фактическое значение Для диагностических случаев, относящихся к службе БД 0616, указанных ниже, здесь должен быть указан OBDMID. OBDMID должен быть введен в шестнадцатеричной форме (например, 1С16). Стандартные значения для двигателей с искровым зажиганием: - мониторинг пропусков зажигания; - мониторинг катализатора; - мониторинг испарительной системы; - вторичный мониторинг воздушной системы; - мониторинг датчика кислорода; - мониторинг нагревателя датчика кислорода; - мониторинг системы рециркуляции картерных газов (EGR) и/или изменяемых фаз газораспределения (VVT). Стандартные значения для дизельных двигателей: - мониторинг пропусков зажигания; - мониторинг топливной системы; - мониторинг катализатора NMHC (катализатор окисления); - мониторинг последующей обработки NOX (катализатор NOX, поглотитель NOX); - мониторинг системы давления наддува; - контроль датчика отработавших газов; - мониторинг фильтра твердых частиц; - мониторинг системы рециркуляции картерных газов (EGR) и/или изменяемых фаз газораспределения (WT) В таблице 40 определен вывод результатов тестов через службу БД 0616 (TID). Таблица 40 — Определение TID службы БД 0616 Ссылка на сводную таблицу БД Присутствует Формат Название метки либо фактическое значение — TID вводится в десятичной форме (например, 132) — Каждый OBDMID может иметь несколько TID Дополнительная информация Элемент службы 06 TID должен быть описан специально для его стратегии мониторинга, поскольку возможно, что симптому принадлежит несколько стратегий мониторинга В таблице 41 определен вывод результатов испытаний через службу внешнего испытательного оборудования 0616 (Unit and Scaling ID). Таблица 41 — Определение службы БД 0616 USID Ссылка на сводную таблицу БД Отсутствует Формат USID вводится в шестнадцатеричной форме (например, 1С16) — Для каждого TID должен быть указан USID. На один OBDMID может быть несколько TID Данный пункт описывает элементы FXD-схемы, определяющие информацию, специфичную для идентификатора функции. Ключ описания (на основе симптомов отказа): специфическое для поставщика уникальное имя идентификатора функции, описанное в соответствии с 6.6. Примечание — Элемент SHORT-NAME идентификатора функции соответствует идентификатору функции файла «а21». Существуют три различных типа идентификатора функции с возможными значениями: - CALCULATION; - VALIDATION; - OTHER — для целей, не связанных с симптомами отказов, например, аварийный режим работы АКПП. При смешивании типов должен использоваться элемент CALCULATION. 7.9.4.1 Элемент LONG-NAME Это специфичное для поставщика имя функции ЭБУ, формируемое идентификатором функции в соответствии со спецификацией HDO LONG-NAME. Пример — DSALSU. 7.Э.4 .2 Элемент VERSION Это версия ECU-FUNC, как указано в элементе «а21» FUNCTION_VERSION, для функции, в которой сконфигурирован FID. Содержит симптомы отказа, которые влияют на FID (т. е. действуют как источник ингибирования), и указываются, если необходимо, вместе с определенным MASK-REF. В таблице 42 определен ссылочный элемент FAULT-SYMPTOM-REFS. Таблица 42 — Определение элемента FAULT-SYMPTOM-REFS Ссылка на сводную таблицу БД Таблица запрещения Формат Перечень симптомов отказа как в файле «а21» Содержит ссылки на другие элементы (например, уровень качества сигнала), которые влияют на FID (например, действуют как источник ингибирования), если необходимо, вместе с конкретным элементом MASK. В таблице 43 определен ссылочный элемент AUXILIARY-OBJECT-REFS. Таблица 43 — Определение элемента AUXILIARY-OBJECT-REFS Ссылка на сводную таблицу БД Таблица запрещения Формат Перечень уровней качества сигнала, как в файле «а2!» В данном элементе каждый FID описывается более подробно (DESC), включая замещающие реакции. Кроме того, он может включать список элементов ЭБУ (например, параметров калибровки), относящихся к этому FID (DATA-DECLARATION-REFS). В таблице 44 определен элемент FID EXPLANATION. Таблица 44 — Определение элемента EXPLANATION Ссылка на сводную таблицу БД Отсутствует Формат Описание в формате XHTML — Валидация и ингибирование должны быть четко различимы — Аварийное выполнение и замещающее действие должны быть описаны, но не должны различаться Вспомогательные объекты — это объекты, которые можно использовать для запрещения вычисления идентификатора функции (FID) так же, как используются симптомы отказов. Следовательно, их использование в конфигурации/определении идентификатора функции идентично использованию симптома отказа. В элементе MASKS должны быть перечислены все маски, на которые ссылаются отдельные подэлементы FAULT-SYMPTOM-REFS каждого FID. Маски используются для детализации (системных) условий, при которых данный симптом отказа или вспомогательные объекты фактически действуют как источник ингибирования. Таким образом, маска может содержать, например, подробную информацию об уровне дефекта или состоянии отладки. Отображение текста предоставляет возможность определить представление текста, например, онлайн-переменную для псевдонима. Этот элемент может использоваться ИТС для замены текстов, которые определены в файле FXD, внутренними именами ИТС или именами, требуемыми законодателем. Отображение 1-в-1 определяется элементом TEXT-MAP, его дочерними элементами TI и его псевдонимом TEXT. В конце симптома отказа допустимо добавлять любое содержание XML с пространством имен, отличающимся от пространства без имени. Это может быть полезно, если в FXD-файле, кроме информации, определенной моделью FXD, должна передаваться и другая информация. Приложение А (обязательное) А.1 Документ FXD XML-схемы А.1.1 Общие положения XML-схема FXD доступна в виде электронного приложения к настоящему стандарту. Для удобства пользования стандартом следующие пункты включают эти документы. А.1.2 FXD-Schema V2.0.0 xml.xsd 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 This schema defines attributes and an attribute group suitable for use by schemas wishing to allow xmkbase, xmklang or xmkspace attributes on elements they define. To enable this, such a schema must import this schema for the XML namespace, e.g. as follows: < schema . . > <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. <type . . > <attributeGroup ref="xml:specialAttrs7> will define a type which will schema-validate an instance element with any of those attributes*;/ xs:documentation> ln 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. ln due course, we should install the relevant ISO 2-and 3-letter codes as the enumerated possible values .. . По адресу: http://www.w3.org/TR/xmlbase/ см. информацию об этом атрибуте. A.1.3 FXD-Schema V.2.0.0 fxd.xsd elementFormDefault="qualified" attributeFormDefault="unqualified"> schemaLocation="xml.xsd'7> minOccurs="0" maxOccurs="unbounded"/> minOccurs="0'7> INFO»maxOccurs=»unbounded»/> minOccurs="0'7> maxOccurs="unbounded'7> substitutionGroup="OPERAND"/> type="LINK7> maxOccurs="unbounded7> maxOccurs="unbounded"/> maxOccurs="unbounded'7> maxOccurs="unbounded"/> type="FAULT-DETECTION-CRITERIA'7> type="OK-DETECTION-CRITERIA" nillable="true'7> type="OK-ENABLE-CONDITIONS" nillable="true'7> type="DISABLE-REPORT-ONLY" minOccurs="07> type="LEGISLATIONS" nillable="true'7> nillable="true'7> nillable="true'7> minOccurs="0'7> minOccurs="0'7> minOccurs="0'7> minOccurs="0'7> minOccurs="07> minOccurs="07> minOccurs="07> minOccurs="0" maxOccurs="unbounded'7> minOccurs="0'7> minOccurs="0" maxOccurs="unbounded"/: minOccurs="07> minOccurs="07> type="CONFIGURATION" minOccurs="07> type="LINK7> type="BIT-FIELD-VARIABLE7> A.2 Список отображения элементов FXD XML-схемы В таблице A. 1 перечислены элементы FXD XML-схемы, приведенные в настоящем стандарте. Примечание — Ссылочные элементы не перечислены (например, FAULT-SYMPTOM-REFS). Таблица А.1 — Список соответствия элементов 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-INFO 7.6.12 CENTRAL-CALIBRATION-INFOS CENTRAL-CALIBRATION-INFOS 7.6.12 CENTRAL-CALIBRATION-INFOS Продолжение таблицы А. 1 Элемент FXD XML-схемы Атрибуты Пункт Заголовок пункта в настоящем стандарте 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 7.5.1 Формальное описание алгоритмов диагностики COMPUTATIONS Основные положения COMPUTATIONS 7.4.2 COMPUTATIONS CONFIGURATION 7.6.5 CONFIGURATION CUSTOM-CODE 7.6.6.2 CUSTOM-CODES CUSTOM-CODES xsknil 7.6.6.2 CUSTOM-CODES DATA 7.4.1 DATA-DECLARATIONS DATA-DECLARATION ID 4.3.2.1 6.5 7.4.1 7.5.1 Основные требования Ссылки на переменные ЭБУ и калибровочные метки DATA-DECLARATIONS Основные положения 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 Tl 4.5.2 6.4 6.6 7.9.7 Формальное описание алгоритмов диагностики Ссылки на внешние документы Общие элементы FXD, используемые для идентификации и описания Элемент EXPLANATION DISABLE-FULLY 7.6.11.14 DISABLE-FULLY DISABLE-REPORT-ONLY 7.6.11.13 DISABLE-REPORT-ONLY DISPLAY-NAME Tl 7.4.1 7.4.3 DATA-DECLARATIONS 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 7.5.4.2 7.5.4 Элемент LONG-NAME Элемент VERSION Элемент ECU-FUNCS ECU-FUNCS 7.5.4 Элемент ECU-FUNCS Элемент FXD XML-схемы Атрибуты Пункт Заголовок пункта в настоящем стандарте ENABLE-CONDITIONS xsknil 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 7.6.11.1 FAULT-DETECTIONS Основная информация 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 xsktype DESC-STATE DESC-EXTENT xmklang 4.4 4.5.4 7.6 Формат FXD и пример Реализация наследования значений 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 xmkbase xmklang 6.1.10 6.1.11 6.1.12 Атрибут VERSION (содержание) Атрибут xmkbase (инфраструктура) Атрибут xmklang (инфраструктура) 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 Продолжение таблицы А. 1 Элемент FXD XML-схемы Атрибуты Пункт Заголовок пункта в настоящем стандарте INITIAL-STATE 7.5.9 STATE-GRAPH LEGAL-CODE xsknil 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 7.5.4.1 7.5.8 7.6.4.1 7.9.4.1 Общие элементы FXD, используемые для идентификации и описания LONG-NAME BIT-FIELD-VARIABLE LONG-NAME 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 7.2.5 PROJECT 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 xsknil 7.6.11.11 OK-DEBOUNCE OK-DETECTION-CRITERIA xsknil 7.6.11.9 OK-DETECTION-CRITERIA OK-ENABLE-CONDITIONS xsknil 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 Элемент FXD XML-схемы Атрибуты Пункт Заголовок пункта в настоящем стандарте 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 7.2.5 PROJECT RESOURCES TEXT-MAP 7.12 TEXT-MAPPINGS TEXT-MAPPING xmklang 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 Окончание таблицы А1 Элемент FXD XML-схемы Атрибуты Пункт Заголовок пункта в настоящем стандарте UNITS 7.4.3 UNIT-SPEC VARIABLE-DESCRIPTION xshtype DESC-STATE DESC-EXTENT xml:lang ID SI OID 7.5.3 7.5 7.5.3 7.5.5 COMPANY-DATA-REF VARIABLE-DESCRIPTIONS COMPANY-DATA-REF CONFIGURATION VARIABLE-DESCRIPTIONS 7.5.1 Основные положения VT Tl 4.5.2 Формальное описание алгоритмов диагностики А.З Операторы для элемента ABSTRACT-SYNTAX Операторы для элемента ABSTRACT-SYNTAX — это вычисления FXD, которые в основном используются для документирования, а не для оценки; строгий набор текста нежелателен. Тем не менее вычисления или их части можно рассматривать как оцениваемые вычисления. В этом случае требуется подробное определение аргументов операторов и возвращаемых значений. FXD определяет три типа значений: а) логический: - значение может быть только истинным или ложным; - это либо элемент COMPU-CONST/VB, либо результат логической операции; б) числовой: - значение должно быть числом (целое число или число с плавающей запятой, представляющее в большинстве случаев физическое значение); - это либо элемент COMPU-CONST/V, либо результат числовой операции; в) строковый: - значение может быть произвольным текстовым содержимым; - предполагается, что COMPU-CONST/VT (строки) представляют собой описание значения соответствующего типа. В таблице А.2 определены оцениваемые типы операторов FXD, т. е. как операторы ведут себя или будут вести себя, если аргументы имеют заданный тип и, если требуется, оценку. Примечание «переменная» означает, что аргумент на самом деле должен быть переменной, а не постоянным значением. Таблица А.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 Округление до следующего целого числа, большего или равного значению Числовой Числовой — — delay3 2 Значение задерживается на определенное время. Первый аргумент — это условие, второй аргумент — время задержки. Задержка (n > n_min и n < n_max, 10*мс) выражает ситуацию, когда условие было выполнено, как минимум, в течение 10 мс Логический Логический Числовой delta 1 Разность между текущим и ранее рассчитанным значениями переменной, например: A(temp). Это эквивалентно temp — предыдущее (temp) Числовой Числовой div 2 Деление Числовой Числовой Числовой — duration_ ofh 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, выходное значение будет истинным в течение одного периода выборки Логический Логический eqc 2 Равно. Два значения могут быть равны, только если они имеют один тип Логический Любой Любой — floor 1 Округление до следующего целого числа, меньшего или равного значению Числовой Числовой — — ge 2 Больше либо равно Логический Числовой Числовой — getbit 2 Определяет значение n-го бита в выражении, описанном первым параметром. Положение бита определяется вторым параметром (начиная с 0) Логический Числовой Числовой Продолжение таблицы А.2 Функция/ оператор Минимальное/ максимальное количество параметров функции Объяснение Тип результата Тип первого параметра Тип второго параметра Тип третьего и последующих параметров gradient 2 Отношение разности между текущим и предыдущим значениями переменной и соответствующей разницы во времени или угле, в которых проводились вычисления, например, gradient(temp,1s). Это эквивалентно A(temp)/1s и (temp-previous(temp))/1 s Числовой Числовой Числовой gt 2 Больше чем Логический Числовой Числовой if1 3 Условное выражение, рассматриваемое как функция с тремя (С, Т, Е) аргументами, где С — условие, Т — результат при С = истина, Е — результат при С = ложь. Простой пример различения двух значений в зависимости от бита: если (B_manualtransmission, 6,4) Пример для вложенных if: if(B_ manualtransmission, if(B_4wheel, 8,6),4) Любой Логический Любой Любой Ie 2 Меньше либо равно Логический Числовой Числовой It 2 Меньше чем Логический Числовой Числовой max 21с динамической длиной Максимум из разных значений Числовой Числовой Числовой Числовой min 2/с динамической длиной Минимум из разных значений Числовой Числовой Числовой Числовой max_ value 1 или 1+2*п (п обозначает размер метки) Оценивает максимальное значение поля. Первый операнд — это имя метки. Если последующие операнды не указаны, оценивается общий максимум. Если имеется п пар дополнительных операндов, каждая пара указывает диапазон для одной оси, сообщая первый и последний индексы, которые необходимо учитывать для вычисления максимального значения Числовой Переменный Числовой Числовой Функция/ оператор Минимальное/ максимальное количество параметров функции Объяснение Тип результата Тип первого параметра Тип второго параметра Тип третьего и последующих параметров min_ value 1 или 1+2*п (п обозначает размер метки) Оценивает минимальное значение поля. Первый операнд — это имя метки. Если последующие операнды не указаны, оценивается общий минимум. Если имеется п пар дополнительных операндов, каждая пара указывает диапазон для одной оси, сообщая первый и последний индексы, которые необходимо учитывать для вычисления минимального значения Числовой Переменный Числовой Числовой mul 2/с динамической длиной Умножение Числовой Числовой Числовой Числовой neqe 2 Не равно. Два значения разных типов всегда не равны Логический Любой Любой — nop 0/с динамической длиной Операция отсутствует Любой Любой — — not 1 Логическое «не» Логический Логический — — notef 2 Цель оператора Note — предоставить простую возможность объяснить последующие условия коротким словесным выражением. Соответственно, первый аргумент является текстовой строкой, второй аргумент является вычислением, сформулированным в ABSTRACT-SYNTAX (см. 7.4.2) Любой Строковый Любой or 2/с динамической длиной Логическое «или» Логический Логический Логический Логический pow 2 Степень числа, экспоненциальная функция, pow(a,b) = аь Числовой Числовой Числовой — previous9 1 Доступ к ранее рассчитанному значению переменной, например: - previous(B_state); - previous(temp) Числовой Переменный — — shiftjeft 2 Сдвиг влево (заполнение 0) Числовой Числовой Числовой — shift_right 2 Сдвиг вправо (заполнение 0) Числовой Числовой Числовой — Окончание таблицы А. 2 Функция/ оператор Минимальное/ максимальное количество параметров функции Объяснение Тип результата Тип первого параметра Тип второго параметра Тип третьего и последующих параметров sqrt 1 Квадратный корень числа, Vx Числовой Числовой — — sub 2 Вычитание Числовой Числовой Числовой — value 1+п (п обознача ет размер метки) Оператор значения оценивает значение поля, указав имя поля в качестве первого параметра и «значение оси» для каждого измерения поля в качестве следующих параметров. Поле может быть любой формы/размера, например, кривая, карта, индексная таблица. Поле определяется произвольным количеством опорных точек для каждого измерения. - при доступе к элементу поля через индекс поддерживающие точки представляют значения индекса, например, значение (KnockLevel, CylNo); - доступ к элементу поля путем выбора ближайшей нижней опорной точки без интерполяции; - доступ к элементу поля путем вычисления результата с помощью (линейной) интерполяции Числовой Переменный Числовой Числовой within 2/3 Within(A, В): определяет диапазон Within(X, А, В) — истина, если значение X находится в диапазоне А—В, в противном случае — ложь Логический Числовой Числовой Числовой xor 2 Исключительная дизъюнкция, также называемая «эксклюзивной ИЛИ» Логический Логический Логический Логический a Тип первого параметра определяет тип результата. ь Оператор for_time устарел: вместо него должен использоваться оператор duration of. с Это означает, что логическое значение и числовое значение всегда не равны. d Идентичные типы второго и третьего параметров определяют тип результата. е Сравнение логического и числового значений не допускается. f Тип второго параметра определяет тип результата. 9 Тип первого параметра определяет тип результата. Приложение В (обязательное) В.1 Документы словаря выбора FXD В.1.1 Основные положения FXD XML-схема доступна в виде электронного приложения к настоящему стандарту. Для удобства пользования стандартом следующие пункты включают эти документы. В.1.2 FXD-Selection-Dictionary V.I.I.O.xsd Generic reference to another element in the schema instance document. The list of selectable values. B.1.3 FXD-Selection-Dictionary V1.2.0.xml eSchemaLocation="FXD-Selection-Dictionary_V1.1.0.xsd" VERSION="1.2.0"> 1.1,0 RELEASED 2016-05-13T10:39:56+02:00 First version ->ISO MainDocument 8.6.7 1.2.0 RELEASED 2016-11 -11T14:18:37+01:00 new Elements added OTHER RELEASED Accelerator Pedal Position (APP) Sensor DEPRECATED Accelerator Pedal Position (APP) Sensor 1 RELEASED Accelerator Pedal Position (APP) Sensor 1 and 2 RELEASED Accelerator Pedal Position (APP) Sensor 2 RELEASED Active Grille Air Shutter RELEASED Active Lambda Diagnosis RELEASED Air Conditioning (A/C) Compressor Control RELEASED Air Conditioning (A/C) Compressor Relay RELEASED Air Conditioning (A/C) Compressor Sensor RELEASED Airbag DEPRECATED Airbag Control Modul RELEASED FXD_SL_MC_0005 Ambient Air Temperature (AAT) Sensor RELEASED Autoignition RELEASED Barometric Pressure (BARO) Sensor RELEASED Battery Energy Control Module (BECM) RELEASED FXD_SL_MC_0008 Battery Module RELEASED Battery Voltage RELEASED Boost Pressure DEPRECATED Boost Pressure Control DEPRECATED Brake Booster Pressure Sensor RELEASED Brake Light Switch RELEASED Brake Pedal Position (BPP) Sensor RELEASED Brake Vacuum Pump RELEASED Camshaft Position (CMP) Sensor RELEASED Camshaft Position (CMP) Sensor 2 RELEASED Camshaft Position (CMP) Sensor 3 RELEASED Camshaft Position (CMP) Sensor 4 RELEASED Camshaft Position (CMP) Sensor lnlet DEPRECATED Camshaft Position (CMP) Sensor Inlet 2 DEPRECATED Camshaft Position (CMP) Sensor Outlet DEPRECATED Camshaft Position (CMP) Sensor Outlet 2 DEPRECATED Camshaft Position / Crankshaft Position (CMP/CKP) Sensor lnlet DEPRECATED Camshaft Position / Crankshaft Position (CMP/CKP) Sensor Outlet DEPRECATED CAN: Brake System Control Module (BSCM) RELEASED CAN: Hybrid RELEASED CAN: Instrument Panel Cluster (IPC) RELEASED CAN: Master/Slave RELEASED CAN: Powertrain RELEASED Catalyst System RELEASED Charge Air Cooler (CAC) RELEASED Charge Air Cooler (САС) Coolant Pump RELEASED Charge Air Cooler (CAC) Coolant Temperature Sensor RELEASED FXD_SL_MC_0028 Charge Air Cooler Temperature (CACT) Sensor DEPRECATED Charge Air Cooler Temperature (CACT) Sensor 2 DEPRECATED Cold Start Detection RELEASED Cold Start Fuel lnjector RELEASED Cold Start Strategy RELEASED COM: Active Grille Air Shutter RELEASED COM: Active Grille Air Shutter 2 RELEASED COM: Airbag Control Module RELEASED COM: All Wheel Drive Control Module (AWDCM) RELEASED COM: Ambient Air Temperature (AAT) Sensor RELEASED COM: Barometric Pressure (BARO) Sensor RELEASED COM: Battery Charger Control Module (BCCM) RELEASED COM: Battery Energy Control Module (BECM) RELEASED COM: Body Control Module (BCM) RELEASED COM: Body Control Module (BCM) 1 RELEASED COM: Body Control Module (BCM) 2 RELEASED COM: Brake Booster Pressure Sensor RELEASED COM: Brake Pressure Sensor RELEASED COM: Brake System Control Module (BSCM) RELEASED COM: Climate Control (CC) RELEASED COM: Clutch Control Module RELEASED COM: Device Driver DEPRECATED COM: Door Control Module RELEASED COM: Drive Motor Control Module (DMCM) RELEASED COM: Electric Vacuum Pump RELEASED COM: Electronic Brake Boost Control Module (EBBC) RELEASED COM: Electronic Power Steering Control RELEASED COM: Engine Coolant Temperature (ECT Sensor @ Cylinder Head) DEPRECATED COM: Engine Hood RELEASED COM: Engine Hood Switch DEPRECATED COM: Exhaust Gas Recirculation (EGR) Actuator RELEASED COM: Exhaust Gas Recirculation (EGR) Actuator 2 RELEASED FXD_SL_MC_0310 COM: Exhaust Gas Temperature (EGT) Sensor upstream Turbocharger (TC) RELEASED COM: Front Radar System RELEASED COM: Fuel Filler Door RELEASED COM: Fuel Fired Passenger Compartment Heater RELEASED COM: Fuel Heating Module RELEASED COM: Fuel Level (FL) Sensor RELEASED COM: Fuel Level (FL) Sensor 1 RELEASED COM: Fuel Level (FL) Sensor 2 RELEASED COM: Fuel Level (FL) Sensor 3 RELEASED COM: Fuel Level (FL) Sensor 4 RELEASED COM: Fuel Pump (FP) RELEASED COM: Fuel Pump Control Module (FPCM) RELEASED COM: Fuel System RELEASED COM: Gateway RELEASED COM: Glow Plug Control Module (GPCM) RELEASED COM: Glow Plug Control Module (GPCM) 1 and 2 RELEASED COM: Glow Plug Control Module (GPCM) 2 RELEASED COM: Glow Plug lndicator RELEASED COM: Hybrid Battery Pack Sensor Module RELEASED COM: Instrument Panel Cluster (IPC) RELEASED COM: Ion Current System (ICS) RELEASED COM: Level Control System RELEASED COM: Longitudinal Acceleration Sensor RELEASED COM: Master/Slave RELEASED COM: Nitrogen Oxides (NOX) Sensor RELEASED COM: Nitrogen Oxides (NOX) Sensor 2 RELEASED COM: Non-Methane Hydrocarbon (NMHC) Catalyst Heater Control Module RELEASED COM: NOx Sensor DEPRECATED COM: Particulate Matter Sensor (PMS) RELEASED COM: Power Steering Control (PSC) Module RELEASED COM: Refueling Button RELEASED COM: Selective Catalytic Reduction (SCR) Control Module RELEASED COM: Starter Generator Control Module (SGCM) RELEASED COM: Supplementary Coolant Pump RELEASED COM: Thermal Management Control Module RELEASED COM: Torque Converter Clutch (TCC) RELEASED COM: Transmission Control Module (TCM) RELEASED COM: Transmission Control Module (TCM) Hybrid RELEASED COM: Turbocharger (TC) Compressor Actuator RELEASED COM: Turbocharger (TC) Control Module RELEASED COM: Vehicle Speed DEPRECATED COM: Vehicle Speed Sensor (VSS) RELEASED Compressed Natural Gas (CNG) Fuel lnjector RELEASED Compressed Natural Gas (CNG) Fuel Pressure Sensor RELEASED Compressed Natural Gas (CNG) Fuel Rail Pressure (FRP) Control RELEASED Compressed Natural Gas (CNG) Fuel Tank Pressure (FTP) Sensor RELEASED Compressed Natural Gas (CNG) Fuel Tank System RELEASED Compressed Natural Gas (CNG) Fuel Volume Regulator Control RELEASED Compressed Natural Gas (CNG) Inertia Fuel Shutoff (IFS) Actuator RELEASED Coolant Pump DEPRECATED Coolant Pump (Auxiliary) Relay DEPRECATED Coolant Pump (Auxiliary) Relay 2 DEPRECATED FXD_SL_MC_0060 Coolant Pump (Low-Temperature Circuit) DEPRECATED Coolant Pump (Supplementary) DEPRECATED Coolant Pump Charge Air Cooler (CAC) DEPRECATED Crankcase Heater RELEASED Crankshaft Position (CKP) Sensor RELEASED Cylinder Deactivation (CD) Actuator Control RELEASED Cylinder Pressure Sensor RELEASED Diesel Particulate Filter (DPF) RELEASED Diesel Particulate Filter (DPF) 2 RELEASED Diesel Particulate Filter (DPF) Pressure Sensor RELEASED Diesel Particulate Filter (DPF) Pressure Sensor 1 and 2 RELEASED Diesel Particulate Filter (DPF) Pressure Sensor downstream hose line RELEASED Diesel Particulate Filter (DPF) Pressure Sensor upstream hose line RELEASED Direct Ozone Reduction (DOR) Temperature Sensor DEPRECATED Drive Motor Control Module (DMCM) DEPRECATED Drive Motor Coolant Bypass Valve RELEASED ECM: RAM DEPRECATED Electric Drive Motor RELEASED Engine Compartment Temperature Sensor RELEASED Engine Components Supply Voltage Relay RELEASED Engine Control Module (ECM) RELEASED Engine Control Module (ECM): 5V Supply Voltage RELEASED Engine Control Module (ECM): Analog / Digital Converter RELEASED Engine Control Module (ECM): Analog / Digital Converter 2 RELEASED Engine Control Module (ECM): Barometric Pressure (BARO) Sensor RELEASED Engine Control Module (ECM): Battery Supply Voltage RELEASED Engine Control Module (ECM): Brake System RELEASED Engine Control Module (ECM): Checksum RELEASED Engine Control Module (ECM): Coding RELEASED Engine Control Module (ECM): Communication RELEASED Engine Control Module (ECM): Cylinder Deactivation (CD) RELEASED Engine Control Module (ECM): Dual lnjection RELEASED Engine Control Module (ECM): EEPROM RELEASED Engine Control Module (ECM): Electronic Throttle Control Module DEPRECATED Engine Control Module (ECM): Electrically Erasable Programmable Read Only Memory (EEPROM) DEPRECATED Engine Control Module (ECM): Electronic Throttle Control Module RELEASED Engine Control Module (ECM): Fuel Injection Valves DEPRECATED Engine Control Module (ECM): Fuel lnjector RELEASED Engine Control Module (ECM): Fuel System RELEASED Engine Control Module (ECM): Fuel Volume Regulator Control RELEASED Engine Control Module (ECM): Hybrid Electric Vehicle (HEV) RELEASED Engine Control Module (ECM): Ignition Control (IC) RELEASED Engine Control Module (ECM): Ignition Control (IC) 2 RELEASED Engine Control Module (ECM): Inertia Fuel Shutoff (IFS) DEPRECATED Engine Control Module (ECM): Internal Timer RELEASED Engine Control Module (ECM): Multi lnjection RELEASED Engine Control Module (ECM): Oxygen Sensor RELEASED Engine Control Module (ECM): Oxygen Sensor (O2S) DEPRECATED Engine Control Module (ECM): Pre-Delivery Road Test Mode RELEASED Engine Control Module (ECM): Processor RELEASED Engine Control Module (ECM): Processor xxx DEPRECATED Engine Control Module (ECM): Production Mode RELEASED Engine Control Module (ECM): RAM RELEASED Engine Control Module (ECM): Random Access Memory (RAM) DEPRECATED Engine Control Module (ECM): Random Only Memory (ROM) DEPRECATED Engine Control Module (ECM): Reset RELEASED Engine Control Module (ECM): Sensor Integrated Circuit RELEASED Engine Control Module (ECM): Sensor Reference Circuit A RELEASED Engine Control Module (ECM): Sensor Reference Circuit B RELEASED Engine Control Module (ECM): Sensor Reference Circuit C RELEASED Engine Control Module (ECM): Sensor Reference Circuit D RELEASED Engine Control Module (ECM): Service Mode RELEASED Engine Control Module (ECM): Temperature Sensor RELEASED FXD_SL_MC_0090 Engine Control Module (ECM): Transport Mode RELEASED Engine Control Module (ECM): Variable Valve Lift (VVL) System RELEASED Engine Control Module (ECM): Watchdog Shutdown RELEASED Engine Coolant Fan DEPRECATED Engine Coolant Fan 2 DEPRECATED Engine Coolant System: Bypass Actuator RELEASED Engine Coolant Temperature (ECT) @ Cylinder Block DEPRECATED Engine Coolant Temperature (ECT) @ Cylinder Head DEPRECATED Engine Coolant Temperature (ECT) @ Radiator lnlet DEPRECATED Engine Coolant Temperature (ECT) @ Radiator Outlet DEPRECATED Engine Coolant Temperature (ECT) Sensor RELEASED Engine Coolant Temperature (ECT) Sensor @ Crankcase RELEASED Engine Coolant Temperature (ECT) Sensor @ Cylinder Block RELEASED Engine Coolant Temperature (ECT) Sensor @ Cylinder Head RELEASED Engine Coolant Temperature (ECT) Sensor @ Radiator 1 Outlet RELEASED Engine Coolant Temperature (ECT) Sensor @ Radiator 2 Outlet RELEASED Engine Coolant Temperature (ECT) Sensor @ Radiator Outlet RELEASED Engine Coolant Temperature (ECT) Sensor downstream engine RELEASED Engine Cooling System RELEASED Engine Cooling System (low temperature) DEPRECATED Engine Cooling System: Bypass Valve DEPRECATED Engine Cooling System: Thermostat Heater Control RELEASED Engine Fuel Temperature (EFT) Sensor RELEASED Engine Off Time RELEASED Engine Oil Level Sensor RELEASED Engine Oil Pressure (EOP) Sensor RELEASED Engine Oil Pump RELEASED Engine Oil Temperature (EOT) Sensor RELEASED Engine Oil Temperature (EOT) Sensor @ Cylinder Head RELEASED Engine Oil Temperature (EOT) Sensor @ main oil gallery RELEASED Engine Speed (RPM) Sensor DEPRECATED Engine Speed Sensor RELEASED Ethanol (ETH) Sensor RELEASED Ethanol (ETH) Temperature Sensor DEPRECATED Ethanol (ETH) Temperature Sensor RELEASED Evaporative Emission (EVAP System Vent Valve) DEPRECATED Evaporative Emission (EVAP) Canister Pipe Pressure Sensor RELEASED Evaporative Emission (EVAP) Canister Purge Valve RELEASED Evaporative Emission (EVAP) Canister Purge Valve 2 RELEASED Evaporative Emission (EVAP) Fuel Tank Pressure Sensor RELEASED Evaporative Emission (EVAP) Fuel Vapor Temperature Sensor RELEASED Evaporative Emission (EVAP) Leak Detection Pump (LDP) RELEASED Evaporative Emission (EVAP) Pressure Sensor RELEASED Evaporative Emission (EVAP) Pressure Sensor 2 RELEASED Evaporative Emission (EVAP) System RELEASED Evaporative Emission (EVAP) System (High Pressure Purge Line) RELEASED Evaporative Emission (EVAP) System Fuel Filler Door RELEASED Evaporative Emission (EVAP) System Large Leak RELEASED Evaporative Emission (EVAP) System Small Leak RELEASED Evaporative Emission (EVAP) System Vapor Pressure Sensor RELEASED Evaporative Emission (EVAP) System Vent Valve RELEASED Evaporative Emission (EVAP) System Very Small Leak RELEASED Exhaust Camshaft Position (CMP) Sensor RELEASED Exhaust Camshaft Position (CMP) Sensor 2 RELEASED Exhaust Camshaft Position / Crankshaft Position (CMP/CKP) Correlation RELEASED Exhaust Camshaft Position / Crankshaft Position (CMP/CKP) Sensor RELEASED Exhaust Camshaft Position 2/ Crankshaft Position (CMP/CKP) Correlation RELEASED Exhaust Camshaft Position 2/ Crankshaft Position (CMP/CKP) Sensor RELEASED Exhaust Camshaft Position 2/Crankshaft Position (CMP/CKP) Correlation RELEASED Exhaust Flap Actuator RELEASED Exhaust Flap Actuator 2 RELEASED Exhaust Gas Recirculation (EGR) Actuator 1 and 2 RELEASED Exhaust Gas Recirculation (EGR) HP Actuator RELEASED Exhaust Gas Recirculation (EGR) HP Position Sensor RELEASED Exhaust Gas Recirculation (EGR) HP System RELEASED Exhaust Gas Recirculation (EGR) LP Actuator RELEASED Exhaust Gas Recirculation (EGR) LP Position Sensor RELEASED Exhaust Gas Recirculation (EGR) LP Pressure Sensor RELEASED Exhaust Gas Recirculation (EGR) LP System RELEASED Exhaust Gas Recirculation (EGR) Position Sensor 1 and 2 RELEASED Exhaust Gas Recirculation (EGR) Pressure Sensor RELEASED Exhaust Gas Recirculation (EGR) System RELEASED Exhaust Gas Recirculation (EGR) Valve DEPRECATED Exhaust Gas Recirculation (EGR) Valve Actuator DEPRECATED Exhaust Gas Recirculation (EGR) Valve Position Sensor DEPRECATED Exhaust Gas Recirculation Cooler (EGRC) DEPRECATED Exhaust Gas Recirculation Cooler (EGRC) 2 HP System RELEASED Exhaust Gas Recirculation Cooler (EGRC) Bypass Valve DEPRECATED Exhaust Gas Recirculation Cooler (EGRC) HP Bypass Actuator RELEASED Exhaust Gas Recirculation Cooler (EGRC) HP Bypass Actuator 2 RELEASED Exhaust Gas Recirculation Cooler (EGRC) HP System RELEASED Exhaust Gas Recirculation Cooler (EGRC) LP System RELEASED Exhaust Gas Recirculation Temperature (EGRT) Sensor RELEASED Exhaust Gas Temperature (EGT) Sensor RELEASED Exhaust Gas Temperature (EGT) Sensor 2 RELEASED Exhaust Gas Temperature (EGT) Sensor downstream Ammonia Oxidation Catalyst DEPRECATED Exhaust Gas Temperature (EGT) Sensor downstream Diesel Oxidation Catalyst VT> DEPRECATED Exhaust Gas Temperature (EGT) Sensor downstream Diesel Oxidation Catalyst (DOC) RELEASED Exhaust Gas Temperature (EGT) Sensor downstream Diesel Particulate Filter VT> DEPRECATED Exhaust Gas Temperature (EGT) Sensor downstream Diesel Particulate Filter (DPF) RELEASED Exhaust Gas Temperature (EGT) Sensor downstream Exhaust Gas Recirculation (EGR) LP Cooler RELEASED Exhaust Gas Temperature (EGT) Sensor downstream Gasoline Particulate Filter (GPF) RELEASED Exhaust Gas Temperature (EGT) Sensor upstream Diesel Oxidation Catalyst (DOC) RELEASED Exhaust Gas Temperature (EGT) Sensor upstream Diesel Oxydation Catalyst DEPRECATED Exhaust Gas Temperature (EGT) Sensor upstream Diesel Particulate Filter (DPF) RELEASED Exhaust Gas Temperature (EGT) Sensor upstream Gasoline Particulate Filter (GPF) RELEASED Exhaust Gas Temperature (EGT) Sensor upstream Turbocharger (TC) RELEASED Exhaust Pressure (EP) Sensor DEPRECATED Exhaust Pressure (EP) Sensor upstream Turbocharger (TC) RELEASED Exhaust Pressure Regulator (EPR) RELEASED Exhaust Pressure Regulator (EPR) Actuator RELEASED Exhaust Pressure Regulator (EPR) Position Sensor RELEASED Fan Control (FC) RELEASED Fan Control (FC) Module RELEASED FlexRay: Powertrain RELEASED Four-Wheel Drive Clutch Control Module (4WDCM) RELEASED Fuel Balance Control RELEASED Fuel Balance Control Monitoring DEPRECATED Fuel Control Valve DEPRECATED Fuel Heating Module RELEASED Fuel Injection Valve DEPRECATED Fuel Injection Valves DEPRECATED Fuel Injection Valves (High Pressure) DEPRECATED Fuel Injection Valves Compressed Natural Gas (CNG) DEPRECATED Fuel lnjector RELEASED Fuel Injector Supply Voltage RELEASED Fuel Level (FL) Sensor RELEASED Fuel Level Sensor DEPRECATED Fuel Metering Unit RELEASED Fuel Pressure Control (PC) Valve Compressed Natural Gas (CNG) DEPRECATED Fuel Pressure LP Regulator RELEASED Fuel Pressure LP Sensor RELEASED Fuel Pressure LP System RELEASED Fuel Pressure Regulator RELEASED Fuel Pressure Sensor 2, high pressure Side DEPRECATED Fuel Pressure Sensor Compressed Natural Gas (CNG) DEPRECATED Fuel Pressure Sensor, high pressure Side DEPRECATED Fuel Pressure Sensor, low pressure Side DEPRECATED Fuel Pump (FP) RELEASED Fuel Pump (FP) Module DEPRECATED Fuel Pump (FP) Relay RELEASED Fuel Pump (FP) Relay 2 RELEASED Fuel Pump Control (FPC) RELEASED Fuel Pump Control Module (FPCM) RELEASED Fuel Rail Pressure (FRP) Control RELEASED Fuel Rail Pressure (FRP) Control Actuator RELEASED Fuel Rail Pressure (FRP) Control Actuator 2 RELEASED Fuel Rail Pressure (FRP) Control Valve DEPRECATED Fuel Rail Pressure (FRP) Control Valve 2 DEPRECATED Fuel Rail Pressure (FRP) High Pressure Side DEPRECATED Fuel Rail Pressure (FRP) Low Pressure Side DEPRECATED Fuel Rail Pressure (FRP) Sensor RELEASED Fuel Rail Pressure (FRP) Sensor 2 RELEASED Fuel Rail Pressure (FRP) System RELEASED Fuel Rail Pressure Control (PC) Compressed Natural Gas (CNG) DEPRECATED Fuel System RELEASED Fuel System 2 RELEASED Fuel Tank Flap DEPRECATED Fuel Tank Pressure (FTP) Sensor RELEASED Fuel Tank Pressure (FTP) Sensor Compressed Natural Gas (CNG) DEPRECATED Fuel Tank Temperature (FTT) Sensor RELEASED Fuel Temperature Sensor RELEASED Fuel Volume Regulator DEPRECATED Fuel Volume Regulator (high pressure side) DEPRECATED Fuel Volume Regulator Control RELEASED Fuel Volume Regulator Control 2 RELEASED Fuel Volume Regulator HP Control RELEASED Fuel Volume Regulator HP Control 2 RELEASED Gasoline Particulate Filter (GPF) RELEASED Gasoline Particulate Filter (GPF) Pressure Sensor RELEASED Gear Position Sensor RELEASED Glow Plug RELEASED Glow Plug Control Module (GPCM) RELEASED Heating Circuit Bypass Actuator RELEASED Heating Circuit Coolant Pump RELEASED Heating Circuit Temperature Sensor RELEASED Hybrid Clutch RELEASED Hybrid Electric Vehicle (HEV) Electric Clutch RELEASED ldle Controller DEPRECATED ldle Speed Control (ISC) RELEASED ldler Shaft Position Sensor RELEASED lgnition Coil RELEASED lgnition Control (IC) RELEASED lnertia Fuel Shutoff Valve (IFS) Compressed Natural Gas (CNG) DEPRECATED lntake Air (IA) System RELEASED lntake Air Temperature (IAT) Sensor 2 downstream Throttle DEPRECATED lntake Air Temperature (IAT) Sensor RELEASED lntake Air Temperature (IAT) Sensor @ Manifold RELEASED lntake Air Temperature (IAT) Sensor @ Manifold 2 RELEASED lntake Air Temperature (IAT) Sensor @ Mass Air Flow (MAF) RELEASED lntake Air Temperature (IAT) Sensor @ Sensor @ Mass Air Flow (MAF) RELEASED lntake Air Temperature (IAT) Sensor 1 RELEASED lntake Air Temperature (IAT) Sensor 1 and 2 RELEASED lntake Air Temperature (IAT) Sensor 2 RELEASED lntake Air Temperature (IAT) Sensor 2 downstream lntercooler DEPRECATED lntake Air Temperature (IAT) Sensor 2 upstream Throttle DEPRECATED lntake Air Temperature (IAT) Sensor 3 RELEASED lntake Air Temperature (IAT) Sensor 4 RELEASED lntake Air Temperature (IAT) Sensor downstream Air Filter RELEASED lntake Air Temperature (IAT) Sensor downstream Charge Air Cooler (CAC) RELEASED lntake Air Temperature (IAT) Sensor downstream Charge Air Cooler (САС) 2 VT> RELEASED lntake Air Temperature (IAT) Sensor downstream lntercooler DEPRECATED lntake Air Temperature (IAT) Sensor downstream Throttle RELEASED lntake Air Temperature (IAT) Sensor upstream Charge Air Cooler (CAC) RELEASED lntake Air Temperature (IAT) Sensor upstream Throttle RELEASED lntake Air Temperature (IAT) Sensor upstream Throttle 2 RELEASED lntake Camshaft Position (CMP) Sensor RELEASED lntake Camshaft Position (CMP) Sensor 2 RELEASED lntake Camshaft Position / Crankshaft Position (CMP/CKP) Correlation RELEASED lntake Camshaft Position / Crankshaft Position (CMP/CKP) Sensor RELEASED lntake Camshaft Position 2/ Crankshaft Position (CMP/CKP) Sensor RELEASED FXD_SL_MC_0190 lntake Manifold RELEASED lntake Manifold 2 RELEASED lntake Manifold Runner Control (IMRC) Actuator RELEASED lntake Manifold Runner Control (IMRC) Actuator 1 and 2 RELEASED lntake Manifold Runner Control (IMRC) Actuator 2 RELEASED lntake Manifold Runner Control (IMRC) Position Sensor RELEASED lntake Manifold Runner Control (IMRC) Position Sensor 1 and 2 RELEASED lntake Manifold Runner Control (IMRC) Position Sensor 2 RELEASED lnverter Coolant Pump RELEASED lnverter Coolant Temperature Sensor RELEASED lnverter Cooling System RELEASED lnverter Cooling System: Bypass Actuator RELEASED Knock Control RELEASED Knock Sensor (KS) RELEASED Knock Sensor (KS) 2 RELEASED Knock Sensor (KS) 3 RELEASED Knock Sensor (KS) 4 RELEASED Leak Detection Pump (LDP) RELEASED Leak Detection Pump (LDP) Reed Sensor RELEASED LIN: Active Grille Air Shutter RELEASED LIN: Battery Sensor RELEASED LIN: Glow Plug Control Module (GPCM) RELEASED LIN: Oil Level Sensor RELEASED LIN: Powertrain RELEASED LIN: Starter Generator Control Module (SGCM) RELEASED Low-temperature Circuit Coolant Pump RELEASED Low-temperature Circuit Coolant Temperature Sensor RELEASED Low-temperature Circuit Cooling System RELEASED Magnetic Clutch DEPRECATED Main Coolant Pump Actuator RELEASED Main Relay RELEASED Manifold Absolut Pressure (MAP) Sensor DEPRECATED Manifold Absolut Pressure (MAP) Sensor downstream Throttle DEPRECATED Manifold Absolute Pressure (MAP) Sensor RELEASED Manifold Absolute Pressure (MAP) Sensor 1 and 2 RELEASED Manifold Absolute Pressure (MAP) Sensor 2 RELEASED Mass Air Flow (MAF) Sensor RELEASED Mass Air Flow (MAF) Sensor 1 and 2 RELEASED Mass Air Flow (MAF) Sensor 2 RELEASED Misfire RELEASED Natural Vacuum Leak Detection (NVLD) Switch RELEASED Nitrogen Oxides (NOx) Absorber DEPRECATED Nitrogen Oxides (NOx) Catalyst DEPRECATED Nitrogen Oxides (NOx) Sensor DEPRECATED Nitrogen Oxides (NOx) Sensor Front RELEASED Nitrogen Oxides (NOx) Sensor Heater RELEASED Nitrogen Oxides (NOx) Sensor Heater front RELEASED Nitrogen Oxides (NOx) Sensor Heater rear RELEASED Nitrogen Oxides (NOx) Sensor Rear RELEASED Nitrogen Oxides Adsorber Catalyst (NAC) RELEASED Non-Methane Hydrocarbon (NMHC) Catalyst RELEASED Non-Methane Hydrocarbon (NMHC) Catalyst 2 RELEASED Non-Methane Hydrocarbon (NMHC) Catalyst Heater Control Module RELEASED Non-Methane Hydrocarbon (NMHC) Catalyst Temperature Sensor RELEASED Oxidation Catalyst (OC) DEPRECATED Oxygen Sensor (O2S) downstream Catalyst DEPRECATED Oxygen Sensor (O2S) front RELEASED Oxygen Sensor (O2S) front 2 RELEASED Oxygen Sensor (O2S) Heater front RELEASED Oxygen Sensor (O2S) Heater front 2 RELEASED Oxygen Sensor (O2S) Heater rear RELEASED Oxygen Sensor (O2S) Heater rear 2 RELEASED Oxygen Sensor (O2S) rear RELEASED Oxygen Sensor (O2S) rear 2 RELEASED Oxygen Sensor (O2S) upstream Catalyst DEPRECATED Oxygen Sensor (O2S) upstream main Catalyst DEPRECATED Particulate Matter Sensor (PMS) RELEASED Particulate Matter Sensor (PMS) Heater RELEASED Particulate Matter Sensor (PMS) Temperature Sensor RELEASED Passive Lambda Diagnosis (fuel cut off) RELEASED Piston Cooling Oil Control RELEASED Positive Crankcase Ventilation (PCV) RELEASED Positive Crankcase Ventilation (PVC) DEPRECATED Radiator Anti Tamper Device DEPRECATED Radiator Bypass Actuator RELEASED Radiator Outlet Temperature / Ambient Air Temperature Correlation RELEASED Secondary Air Injection (AIR) RELEASED Secondary Air Injection (AIR) 2 RELEASED Secondary Air Injection (AIR) Pressure Sensor RELEASED Secondary Air Injection (AIR) Pump Relay RELEASED Secondary Air Injection (AIR) Valve RELEASED Selective Catalytic Reduction (SCR) Backflow Pump RELEASED Selective Catalytic Reduction (SCR) Catalyst RELEASED Selective Catalytic Reduction (SCR) Catalyst 2 RELEASED Selective Catalytic Reduction (SCR) Catalyst Efficiency RELEASED Selective Catalytic Reduction (SCR) Control Module RELEASED Selective Catalytic Reduction (SCR) Delivery System RELEASED Selective Catalytic Reduction (SCR) Dosing Valve RELEASED Selective Catalytic Reduction (SCR) Dosing Valve 2 RELEASED Selective Catalytic Reduction (SCR) Efficiency DEPRECATED Selective Catalytic Reduction (SCR) Electronic Control Unit (ECU) DEPRECATED Selective Catalytic Reduction (SCR) Heater Circuit RELEASED Selective Catalytic Reduction (SCR) Heater Circuit 1 RELEASED Selective Catalytic Reduction (SCR) Heater Circuit 2 RELEASED Selective Catalytic Reduction (SCR) Heater Circuit 2 Current Sensor RELEASED Selective Catalytic Reduction (SCR) Heater Circuit 3 RELEASED Selective Catalytic Reduction (SCR) Heater Circuit Current Sensor RELEASED Selective Catalytic Reduction (SCR) Heater Control Circuit RELEASED Selective Catalytic Reduction (SCR) Heater Control Circuit 1 RELEASED SL_MC_0244 Selective Catalytic Reduction (SCR) Heater Control Circuit 2 RELEASED Selective Catalytic Reduction (SCR) Pressure Sensor RELEASED Selective Catalytic Reduction (SCR) Pump RELEASED Selective Catalytic Reduction (SCR) Pump Control RELEASED Selective Catalytic Reduction (SCR) Purge Control Valve DEPRECATED Selective Catalytic Reduction (SCR) Reductant Pressure Sensor RELEASED Selective Catalytic Reduction (SCR) Reductant Quality Performance RELEASED Selective Catalytic Reduction (SCR) Reductant Quality Sensor RELEASED FXD_SL_MC_0518 Selective Catalytic Reduction (SCR) Reductant Tank Level Sensor RELEASED FXD_SL_MC_0519 Selective Catalytic Reduction (SCR) Relay RELEASED FXD_SL_MC_0520 Selective Catalytic Reduction (SCR) Reversing Valve RELEASED Selective Catalytic Reduction (SCR) Tank Cap Switch DEPRECATED Selective Catalytic Reduction (SCR) Tank Level Sensor RELEASED Selective Catalytic Reduction (SCR) Tank Temperature Sensor RELEASED Selective Catalytic Reduction (SCR) Transfer Pump DEPRECATED SENT: Accelerator Pedal Position (APP) Sensor 1 RELEASED SENT: Accelerator Pedal Position (APP) Sensor 1 and 2 RELEASED SENT: Accelerator Pedal Position (APP) Sensor 2 RELEASED SENT: Diesel Particulate Filter (DPF) Pressure Sensor RELEASED SENT: Engine Cooling System: Bypass Actuator Position Sensor RELEASED SENT: Engine Oil Pressure (EOP) Sensor RELEASED SENT: Evaporative Emission (EVAP) Fuel Vapor Temperature Sensor RELEASED SENT: Evaporative Emission (EVAP) Pressure Sensor RELEASED SENT: Exhaust Gas Recirculation (EGR) HP Position and Temperature Sensor VT> RELEASED SENT: Exhaust Gas Recirculation (EGR) LP Pressure Sensor RELEASED SENT: Exhaust Gas Recirculation (EGR) Sensor RELEASED SENT: Exhaust Gas Temperature (EGT) Sensor RELEASED SENT: Exhaust Gas Temperature (EGT) Sensor downstream Gasoline Particulate Filter (GPF) RELEASED SENT: Exhaust Gas Temperature (EGT) Sensor upstream Gasoline Particulate Filter (GPF) RELEASED SENT: Fuel Pressure LP Sensor RELEASED SENT: Fuel Rail Pressure (FRP) Sensor RELEASED SENT: Fuel Rail Pressure (FRP) Sensor 2 RELEASED SENT: Gasoline Particulate Filter (GPF) Pressure Sensor RELEASED SENT: Intake Air Temperature (IAT) Sensor @ Manifold RELEASED SENT: Intake Air Temperature (IAT) Sensor @ Manifold 2 RELEASED SENT: Intake Air Temperature (IAT) Sensor @ Manifold 2 and Manifold Absolute Pressure (MAP) Sensor 2 RELEASED SENT: Intake Air Temperature (IAT) Sensor @ Manifold and Manifold Absolute Pressure (MAP) Sensor RELEASED SENT: Intake Air Temperature (IAT) Sensor 3 RELEASED SENT: Intake Air Temperature (IAT) Sensor downstream Charge Air Cooler (CAC) RELEASED SENT: Intake Air Temperature (IAT) Sensor downstream Charge Air Cooler (CAC) 2 RELEASED SENT: Intake Manifold Runner Control (IMRC) Position Sensor RELEASED SENT: Manifold Absolute Pressure (MAP) Sensor RELEASED SENT: Manifold Absolute Pressure (MAP) Sensor 2 RELEASED SENT: Selective Catalytic Reduction (SCR) Reductant Quality Sensor RELEASED SENT: Selective Catalytic Reduction (SCR) Reductant Tank Level Sensor RELEASED SENT: Turbocharger (TC) Boost Pressure Sensor RELEASED SENT: Turbocharger (TC) Boost Pressure Sensor 2 RELEASED SENT: Turbocharger (TC) Boost Pressure Sensor 2 and Intake Air Temperature (IAT) Sensor downstream Charge Air Cooler (CAC) 2 RELEASED SENT: Turbocharger (TC) Boost Pressure Sensor and Intake Air Temperature (IAT) Sensor downstream Charge Air Cooler (CAC) RELEASED SENT: Turbocharger (TC) Position Sensor RELEASED SENT: Turbocharger (TC) Position Sensor 2 RELEASED Start Delay Relay DEPRECATED Starter Generator Control Module (SGCM) RELEASED Stop-Start System RELEASED Supercharger (SC) 2 Boost Pressure Sensor DEPRECATED Supercharger (SC) Boost Pressure Control RELEASED Supercharger (SC) Clutch Actuator RELEASED Supercharger (SC) Control Flap DEPRECATED Supercharger (SC) Control Flap Position Sensor DEPRECATED Supercharger (SC) Speed Sensor RELEASED Supercharger Bypass (SCB) RELEASED Supercharger Bypass (SCB) Actuator RELEASED Supercharger Bypass (SCB) Position Sensor RELEASED Supplementary Coolant Pump RELEASED Supply Voltage Relay Engine Components DEPRECATED Temperature Sensors RELEASED Throttle Actuator RELEASED Throttle Actuator 1 and 2 RELEASED Throttle Actuator 2 RELEASED Throttle Position Sensor (TPS) RELEASED Throttle Position Sensor (TPS) 1 RELEASED Throttle Position Sensor (TPS) 1 and 2 RELEASED Throttle Position Sensor (TPS) 1 Bank 2 RELEASED Throttle Position Sensor (TPS) 2 RELEASED Throttle Position Sensor (TPS) 2 Bank 2 RELEASED Torque Control RELEASED Traction Control System RELEASED Transmission Control Module (TCM) RELEASED Transmission Control System RELEASED Transmission Oil Heating Actuator RELEASED Turbocharger (TC) Actuator RELEASED Turbocharger (TC) Actuator 2 RELEASED Turbocharger (TC) Boost Pressure Control RELEASED Turbocharger (TC) Boost Pressure Control 2 RELEASED Turbocharger (TC) Boost Pressure Sensor RELEASED Turbocharger (TC) Boost Pressure Sensor 1 and 2 RELEASED Turbocharger (TC) Boost Pressure Sensor 2 RELEASED Turbocharger (TC) Bypass Actuator RELEASED Turbocharger (TC) Bypass Actuator 2 RELEASED Turbocharger (TC) Bypass Position Sensor RELEASED Turbocharger (TC) Compressor Actuator RELEASED Turbocharger (TC) Compressor Actuator 2 RELEASED Turbocharger (TC) Compressor Leakage RELEASED Turbocharger (TC) Exhaust Actuator RELEASED Turbocharger (TC) HP Actuator RELEASED Turbocharger (TC) HP Boost Pressure Sensor RELEASED Turbocharger (TC) HP Bypass Actuator RELEASED Turbocharger (TC) HP Bypass Actuator 2 RELEASED Turbocharger (TC) HP Bypass Position Sensor RELEASED Turbocharger (TC) HP Position Sensor RELEASED Turbocharger (TC) LP Actuator RELEASED Turbocharger (ТС) LP Boost Pressure Sensor RELEASED Turbocharger (TC) Position Sensor RELEASED Turbocharger (TC) Speed Sensor RELEASED Turbocharger Bypass (TCBY) DEPRECATED Variable Valve Lift (WL) Actuator, Outlet Open DEPRECATED Variable Valve Lift (WL) RELEASED Variable Valve Lift (WL) 2 RELEASED Variable Valve Lift (WL) Actuator, Inlet Closed DEPRECATED Variable Valve Lift (WL) Actuator, Inlet Open DEPRECATED Variable Valve Lift (WL) Actuator, Outlet Closed DEPRECATED Variable Valve Lift (WL) Exhaust Actuator RELEASED Variable Valve Lift (WL) Exhaust Actuator 2 RELEASED Variable Valve Lift (VVL) Intake Actuator RELEASED Variable Valve Lift (VVL) Intake Actuator 2 RELEASED Variable Valve Lift (VVL) Supply Relay RELEASED Variable Valve Timing (VVT) Actuator lnlet DEPRECATED Variable Valve Timing (VVT) Actuator Outlet DEPRECATED Variable Valve Timing (VVT) Exhaust Actuator RELEASED Variable Valve Timing (VVT) Exhaust Actuator 2 RELEASED Variable Valve Timing (VVT) Intake Actuator RELEASED Variable Valve Timing (VVT) Intake Actuator 2 RELEASED Vehicle Speed DEPRECATED Vehicle Speed Sensor (VSS) RELEASED Zero Fuel Calibration RELEASED Non Electrical Parts Components or concepts that do not have their own electrical control DESO Miscellaneous Collectors for concepts that cannot be assigned clearly. Components that form a small group also are here deposits System Single systems that have an influence on the flue gas ECU Listing of control units and smart Devices Common ECU Functionality Functions in the control unit that are not directly required for the control of the drive components ECM Functionality Functions that are referred to the engine control device Communication Any kind of communication failures on CAN, Lin and FlexRay FXD_SL_MC_SG_008 Engine Control Function Components to the control of the combustion engine FXD_SL_MC_SG_009 Correlation (including deviation and rationality) Sensors Actuators Temperatures T u rbocharger Secondary Air lnjection Valves lgnition Exhaust Gas System Fuel System (including EVAP) Coolant Camshaft or Crankshaft Air Flow Accelerator Pedal A/C Air-Condition Hybrid Component Hybrid Component 1.1.0 RELEASED 2016-05-13T11:28:23+02:00 First version ->ISO MainDocument 8.6.11.8 OTHER Additional information necessary RELEASED continuous RELEASED multiple RELEASED once per driving cycle RELEASED once per driving cycle keep alive RELEASED once per lifetime RELEASED 1.1,0 RELEASED 2016-05-13T11:28:32+02:00 First version ->ISO MainDocument 8.6.9 1.2.0 RELEASED 2016-10-18T10:38:36+02:00 new Groups 'AFRI1/2' and 'PF1/2' added OTHER OTHER RELEASED AIR Secondary Air System Monitor RELEASED FXD_SL_RAG_002 BP Boost Pressure RELEASED CAT1 Catalyst Bank 1 RELEASED FXD_SL_RAG_004 CAT2 Catalyst Bank 2 RELEASED FXD_SL_RAG_005 EGR EGR and/or VVT Monitor RELEASED FXD_SL_RAG_006 EGS Exhaust Gas Sensor RELEASED FXD_SL_RAG_007 EVAP Evaporative System RELEASED FXD_SL_RAG_008 FUEL Fuel System RELEASED FXD_SL_RAG_009 HCCAT NMHC Catalyst RELEASED FXD_SL_RAG_010 NADS NOx Adsorber RELEASED NCAT NOx Catalyst RELEASED O2SK/VT> 02 Sensor Bank 1 RELEASED O2S2 02 Sensor Bank 2 RELEASED PM PM Filter RELEASED SO2S1 Secondary 02 Sensor Bank 1 RELEASED SO2S2 Secondary 02 Sensor Bank 2 RELEASED AFRI1 Air Fuel Ratio Imbalance Bank 1 RELEASED AFRI2 Air Fuel Ratio Imbalance Bank 2 RELEASED PF1 Particulate Filter Monitor Bank 1 RELEASED PF2 Particulate Filter Monitor Bank 2 RELEASED IUMPR Groups Gasoline Definition of IUMPR Groups for Gasoline Engines IUMPR Groups Diesel Definition of IUMPR Groups for Diesel Engines 1.1,0 RELEASED 2016-05-13T11:28:39+02:00 First version ->ISO MainDocument 8.6.11.12.3 1.2.0 RELEASED 2016-10-18T10:46:40+02:00 'Digital Input Communication Loss/Errors' and 'Digital Output Communication Loss/Errors' added lnput Out-of-Range High RELEASED lnput Out-of-Range Low RELEASED lnput Open Circuit RELEASED lnput Rationality Low RELEASED lnput Rationality High RELEASED lnput Other Rationality RELEASED Output Functional RELEASED Output Shorted High RELEASED Output Shorted Low RELEASED Output Open Circuit RELEASED Digital Input Communication Loss/Errors RELEASED Digital Output Communication Loss/Errors RELEASED lnput Components (e/f)(15.2.1) lnput information of comprehensive component. FRO chapter (e/f)(15.2.2) DESO Output Components (e/f)(15.2.2) Output information of comprehensive component. FRO chapter (e/f)(15.2.2) DESO 1.1,0 RELEASED 2016-05-13T11:28:47+02:00 First version ->ISO MainDocument 8.6.10 FXD_SL_REG_000 OTHER RELEASED AIR Secondary Air System Monitoring RELEASED FXD_SL_REG_002 BP Boost Pressure Monitoring RELEASED FXD_SL_REG_003 CAT Catalyst Monitoring RELEASED FXD_SL_REG_004 CCM Comprehensive Components Monitoring RELEASED FXD_SL_REG_005 EGR EGR System Monitoring RELEASED EGS Exhaust Gas Sensor Monitoring RELEASED FXD_SL_REG_007 EVAP Evaporative System Monitoring RELEASED FXD_SL_REG_008 FUEL Fuel System Monitoring RELEASED HCAT Heated Catalyst Monitoring RELEASED HCCAT NMHC Catalyst Monitoring RELEASED HTR Oxygen Sensor Heater Monitoring RELEASED MIS Misfire Monitoring RELEASED NCAT NOx Cat-Adsorber Monitoring RELEASED O2S Oxygen Sensor Monitoring RELEASED PM PM Filter Heater Monitoring RELEASED Readiness Groups Gasoline Definition of Rediness Groups for Gasoline Engines Readiness Groups Diesel Definition of Rediness Groups for Diesel Engines 1.1,0 RELEASED 2016-05-13T11:28:55+02:00 First version ->ISO MainDocument 8.6.16 OTHER RELEASED Remove Component RELEASED Modified Component RELEASED Break Out Box RELEASED External Signal Simulation Box RELEASED Extemal Actuator Simulation Box RELEASED Software Control Strategy RELEASED Not Feasible RELEASED 1.1.0 RELEASED 2016-05-13T11:29:02+02:00 First version ->ISO MainDocument 8.6.11.16 OTHER RELEASED Communication RELEASED Е lectrical RELEASED B.2 Словарь выбора и реестры выбора Целью словаря выбора является передача текста (словесного) спецификации от ИТС к поставщику ЭБУ. Реестры выбора объединяются в словарь выбора. В.2.1 Статус словаря Словарь выбора должен публиковаться только в состоянии «RELEASED». Более ранние записи не должны удаляться, а должны быть переведены в состояние «DEPRECATED» (устаревшее) для сохранения правильных значений в предыдущих контейнерах FXD. Схема словаря выбора определяется в обязательном порядке в файле FXD-Selection-Dictionary_V1.1.0.xsd. В таблице В.1 определено наименование формы запроса на изменение FXD для новых записей в словаре выбора. Таблица В.1 — Наименование формы запроса на изменение FXD для новой записи в словаре выбора Префикс [vehicle manufacturer]_FXD-CRF_SD_xxx Версия Версии обозначаются двузначной нумерацией, начинающейся с заглавной буквы «V». Это означает, что первая версия документа получает название версии «V01». Для каждой последующей версии имя версии будет увеличено, например, на 1 (V02, V03, V04 и т. д.). Файлы со статусом документа получат одну из следующих букв дополнительно (в соответствии с фактическим статусом). Для устаревших документов может использоваться заглавная буква «и». Это соответствует ситуации, когда документ не был обновлен и не была выпущена новая версия Дата Формат даты: YYYYMMDD (ГГГММДД) В.2.2 Реестр выбора определен для следующих подклассов: - MON-COMPONENT (см. В.3.2); - MON-FREQUENCY (см. В.3.3); - RATIO-GROUP (см. В.3.4); - MCL-STRATEGY (см. В.3.5); - READINESS-GROUP (см. В.3.6); - SIMULATION-METHOD (см. В.3.7); - GENERIC-TYPE (см. В.3.8). В.З Реестры выбора В.3.1 Основные положения Элемент «SELECTION-LIST» содержит согласованные отдельные термины («Selections»), которые также могут быть сгруппированы в несколько тем для целей навигации (SELECTION-GROUP). Шаблон (схема) реестра выбора определяется в обязательном порядке в файле «selection-dictionary.xsd». На рисунке В.1 показана схема элемента SELECTION-LIST. В качестве рабочего языка используют английский язык. Используемые термины должны основываться на [1], [2], [3] и законодательстве по БД. Распределение между SHORT-NAME и ITEMS для отдельных терминов («Selections») остается постоянным. Если ИТС желает повторно сопоставить термины с внутренним списком компании, ему необходимо выполнить поиск термина SHORT-NAME в FXD, а затем продолжить переход к списку ссылок. Соглашения об именах и сокращениях отдельных ITEMS являются обязательными, чтобы идентифицировать все содержимое по SHORT-NAMES и сделать возможным их распределение для создателя в любое время. Правило создания заголовка SHORT-NAMES для текста спецификации в отдельном SELECTION LIST определяется следующим образом: - FXD; - далее следуют символы «SL» для реестра выбора. Содержание данных в реестре выбора указывают две или три буквы. SHORT-NAMES для SELECTION ITEMS, которые определены как обязательные, перечислены в соответствующих главах SELECTION LIST. С помощью элемента SELECTION-GROUP можно сгруппировать отдельные спецификации в разделе SELECTION в соответствии с их тематической областью. В.3.2 Реестр выбора MON-CONPONENT Реестр выбора MON-COMPONENT позволяет сделать выбор с целью определения, для какого компонента или системы выполняется описание. SHORT-NAME в данном случае обеспечивает основу для идентификации и начинается с «FXD_». Имя реестра выбора начинается с SL_MC_ и содержит последовательный четырехзначный номер. В реестре выбора для компонента мониторинга указывается определенное SHORT-NAME, имя компонента или системы и статус. Определенный формат: FXD_SL_MC_nnnn В таблице В.2 приведен пример для датчика положения педали акселератора (АРР) MON-COMPONENT 1. Таблица В.2 — Пример для датчика положения педали акселератора (АРР) MON-COMPONENT 1 SHORT-NAME VT STATE FXD_SL_MS_0001 Accelerator Pedal Position (APP) Sensor (датчик положения педали акселератора) RELEASED В.3.3 Реестр выбора MON-FREQUENCY Реестр выбора MON-FREQUENCY позволяет сделать выбор с целью определения частоты запуска монитора. SHORT-NAME в данном случае начинается с «FXD_». Имя реестра выбора начинается с SL_MF_ и содержит последовательную трехзначную нумерацию. В реестре выбора для MON-FREQUENCY указывается определенное SHORT-NAME, вид мониторинга и статус. - Определенный формат: FXD_SL_MF_nnn В таблице В.З определен пример для MON-FREQUENCY (Continuous). Таблица В.З — Пример для MON-FREQUENCY (Continuous) SHORT-NAME VT STATE FXD_SL_MF_001 Continuous (продолжающийся) RELEASED В.3.4 Реестр выбора RATIO-GROUP Реестр выбора RATIO-GROUP позволяет сделать выбор для определения группы отношений, которую можно назначить для симптома. SHORT-NAME в данном случае начинается с «FXD_». Название реестра выбора начинается с SL_RAG_ и содержит последовательную трехзначную нумерацию. В реестре выбора для RATIO-GROUP указывается определенное SHORT-NAME, имя группы отношений и статус. Определенный формат: FXD_SL_RAG_nnn. В таблице В.4 определен пример для PM RATIO-GROUP. Таблица В.4 — Определение примера для PM RATIO-GROUP SHORT-NAME VT STATE FXD_SL_RAG_014 PM RELEASED В.3.5 Реестр выбора MCL-STRATEGY Реестр выбора MCL-STRATEGY позволяет сделать выбор для определения категории законодательства на основе [9]. SHORT-NAME в данном случае начинается с «FXD_». Название реестра выбора начинается с SL_MCL_ и содержит последовательную трехзначную нумерацию. В реестре выбора для MCL-STRATEGY указывается определенное SHORT-NAME, имя группы отношений и статус. Определенный формат: FXD_SL_MCL_nnn. В таблице В.5 приведен пример для верхнего входного значения MCL-STRATEGY вне диапазона. Таблица В.5 — Пример для верхнего входного значения MCL-STRATEGY вне диапазона (Input Out-Of-Range High) SHORT-NAME VT STATE FXD_SL_MCL_001 Input Out-Of-Range High (верхнее входное значение вне диапазона) RELEASED В.3.6 Реестр выбора READINESS_GROUP Реестр выбора RATIO-GROUP позволяет сделать выбор для определения, какая группа готовности может быть назначена для симптома. SHORT-NAME в данном случае начинается с «FXD_». Название реестра выбора начинается с SL_REG_ и содержит последовательную трехзначную нумерацию. В реестре выбора для RATIO-GROUP указывается определенное SHORT-NAME, имя группы отношений и статус. Определенный формат: FXD_SL_REG_nnn В таблице В.6 приведен пример для мониторинга катализатора READINESS-GROUP. Таблица Б.6 — Пример для мониторинга катализатора READINESS-GROUP SHORT-NAME VT STATE FXD_SL_REG_003 Catalyst monitoring (мониторинг катализатора) RELEASED В.3.7 Реестр выбора SIMULATION-METHOD Реестр выбора SIMULATION-METHOD позволяет сделать выбор для определения, какой метод должен использоваться для запуска симптома отказа. SHORT-NAME в данном случае начинается с «FXD_». Название реестра выбора начинается с SL_SM_ и содержит последовательную трехзначную нумерацию. В реестре выбора для SIMULATION-METHOD указывается определенное SHORT-NAME, название метода моделирования и статус. Определенный формат: FXD_SL_SM_nnn. В таблице В.7 приведен пример для SIMULATION-METHOD удаления компонента. Таблица В.7 — Пример для SIMULATION-METHOD удаления компонента SHORT-NAME VT STATE FXD_SL_SM_001 remove component (удаление компонента) RELEASED В.3.8 Реестр выбора GENERIC-TYPE Реестр выбора GENERIC-TYPE позволяет сделать выбор для определения, какой тип диагностики должен быть связан с обнаружением отказа. SHORT-NAME в данном случае начинается с «FXD_». Название реестра выбора начинается с SL_GT_ и содержит последовательную трехзначную нумерацию. В реестре выбора для GENERIC-TYPE указывается определенное SHORT-NAME, имя универсального типа и статус. Определенный формат: FXD_SL_GT_nnn В таблице В.8 приведен пример для коммуникаций GENERIC-TYPE. Таблица В.8 — Пример для коммуникаций GENERIC-TYPE SHORT-NAME VT STATE FXD_SL_GT_001 COMMUNICATION (коммуникации) RELEASED Приложение С (обязательное) С.1 Расшифровка символов и обозначений структуры таблицы — предупреждение: отрицательные примеры, которые не должны использоваться; ST(W — правильное, желательное представление. Рисунок С.1 — Идентификационные символы в таблицах 1 । Ссылка । Тип । Псевдокод Разрешающее условие 1 Bit_1 == 1 AND within (Measurement_value_1_from calibrated_value_1) AND Measurement_value_2 <= calibrated_value_3 ---------- 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— пояснения к отдельным ссылкам в (2) Рисунок С.2 — Пример структуры таблицы с идентификационными символами Примечание — Имя перед квадратными скобками является общим термином. Термин в квадратных скобках показывает точное написание имени элемента. В таблице С.1 приведены определения терминов. Таблица С.1—Определения терминов Тип отображения Аббревиатура Элемент Описание термина LONG-NAME LO-NA LONG-NAME LONG-NAME объекта — это краткое (несколько слов, меньше предложения) описание, понятное пользователям DATA-NAME DA-NA DATA-NAME DATA-NAME объекта — это имя (например, короткое имя), используемое в файле «а21» для этого объекта; обычно это имя, используемое в ПО ЭБУ DISPLAY-NAME DI-NA DISPLAYNAME DISPLAY-NAME объекта является альтернативным именем для инструментов DATA-NAME, представленных в файле «а21». Оно должно использоваться инструментами и представляться пользователям вместо DATA-NAME Окончание таблицы С. 1 Тип отображения Аббревиатура Элемент Описание термина LONG-NAME TEXTMAPPING LO+TE TEXT-MAP TEXT-MAPPING может использоваться для указания альтернативной формулировки для термина или фразы для специальной цели, например, конкретной аудитории DESCRIPTION DESC DESC DESCRIPTION объекта обеспечивает объяснение объекта для восприятия человеком. Обычно оно состоит из нескольких предложений NOTE NOTE — Дополнительная информация о содержании следующего раздела С.2 Категории Для составления описаний FXD на основе симптомов требуются разные типы информации. Они делятся на следующие категории: - С.З — основные правила FXD. Данная категория показывает элементарные правила FXD; - С.4 — правила подготовки данных. Данная категория показывает правила, предписывающие тип информации, который должен быть представлен; - С.5 — правила представления. Данная категория показывает, как информация должна быть представлена. С.З Основные правила FXD С.3.1 Введение В следующих пунктах представлен общий обзор отказов: - С.3.2 — описание основ; - С.3.3 — описания на основе симптомов; - С.3.4 — область описания симптомов; - С.3.5 — определение разрешающих условий и критериев обнаружения отказов; - С.3.6 — напряжение аккумулятора и состояние клемм; - С.3.7 — темы, которые не следует описывать; - С.3.8 — правила абстракции. С.3.2 Описание основ Описывается только путь, который приводит к обнаружению или устранению отказа. Здесь должны быть перечислены все условия, критерии и параметры, которые необходимы для разрешения или оценки монитора. Начальная точка для обнаружения отказа: - для всех описаний можно предположить, что компонент (система) явно (однозначно и постоянно) неисправен; - затем описание должно быть ограничено для представления «Что делает ПО для обнаружения отказа?». Начальная точка для устранения отказа: - для всех описаний можно предположить, что компонент (система) явно (однозначно и постоянно) исправен; - затем описание должно быть ограничено для представления «Что делает ПО для устранения отказа?». С.3.3 Описания на основе симптомов С.3.3.1 Введение Структура XML-схемы в контейнере FXD основана на симптомах. Поэтому все описания должны быть специфическими для симптомов. Это означает, что описания различных симптомов, которые могут быть «связаны», должны четко отличаться друг от друга. С.3.3.2 Пример содержания описания В таблице С.2 приведен отрицательный пример содержания описания. Таблица С.2 — Отрицательный пример содержания описания s ~у Ссылка Тип Псевдокод И[$торД > < Разрешающие условия Bit_1 == 1 AND within (measurement_value_1_from enable_threshold_value_1 to enable_ threshold_value_2) AND Окончание таблицы С.2 > —ч Ссылка Тип Псевдокод > < 1 2 2 2 2 2 measurement_value_2 <= enable_threshold_value_3 OR measurement_value_2 > enable_threshold_value_3 AND measurement_value_3 >= enable_threshold_value_4 AND measurement_value_4 <= enable_threshold_value_5 Ссылка 1 2 Данное разрешающее условие относится к описанному симптому (правильному). Данное разрешающее условие относится не к описанному симптому, а к другому (неправильному) С.3.4 Область описания симптомов Все частичные функции, спецификации стратегии (например, частичная нагрузка, полная нагрузка), варианты переключения между различными пороговыми значениями (например, с помощью кодового слова, битовых масок) и т. п., которые могут быть выбраны с помощью калибровки, должны быть в целом описаны. Должна быть обеспечена возможность обнаружения и устранения фактического отказа посредством тестирования с использованием всех этих условий/параметров. Также с помощью этого правила должны быть определены те условия/критерии/параметры, которые не должны документироваться в соответствии с правилами FXD, описанными в следующих разделах. С.3.5 Определение разрешающих условий и критериев обнаружения отказов С.3.5.1 Введение Должно быть сделано четкое различие между разрешающими условиями [ENABLE-CONDITIONS] и критериями обнаружения отказов [FAULT-DETECTION-CRITERIA] (см. рисунок С.2). Примечание — Имена разрешающих условий или критериев обнаружения отказов перед квадратными скобками — это общие термины. Термин в квадратных скобках показывает точное написание имени элемента. С.3.5.2 Примеры разрешающих условий и критериев обнаружения отказов На рисунке С.З показана иллюстрация ПО. Разрешающие условия Критерий обнаружения < отказа Рисунок С.З — Иллюстрация ПО В таблице С.З приведен положительный пример разделения разрешающих условий и критериев обнаружения отказов. Таблица С.З — Положительный пример разделения разрешающих условий и критериев обнаружения отказов Ссылка Тип Псевдокод Критерий обнаружения отказа 1 measurement_value_1 > detection_threshold_value_1 Условия разрешения 1 measurement_value_2 > enable_threshold_value_2 AND ignition == 1.0 Ссылка 1 Четкое разделение разрешающих условий и критериев обнаружения отказов В таблице С.4 приведен отрицательный пример идентичных разрешающих условий и критериев обнаружения отказов. Таблица С.4 — Отрицательный пример идентичных разрешающих условий и критериев обнаружения отказов Ссылка Тип Псевдокод Критерий обнаружения отказа measurement_value_1 > detection_threshold_value_1 Разрешающие условия 1 measurement_value_2 > enable_threshold_value_2 AND ignition == 1.0 AND measurement_value_1 > detection_threshold_value_1 Ссылка 1 Критерии обнаружения отказов не должны быть указаны в разрешающих условиях С.3.6 Напряжение аккумулятора и состояние клемм С.3.6.1 Введение Если монитор включен, в зависимости от таких параметров, как напряжение батареи и состояние клемм, эта информация должна быть указана. С.3.6.2 Примеры напряжения батареи/зажигания В таблице С.5 приведен положительный пример напряжения батареи/зажигания. Таблица С.5 — Положительный пример напряжения батареи/зажигания Ссылка Тип Псевдокод Критерий обнаружения отказа 1 1 LO-NA LO-NA ignition == 1.0 AND Bit_2 == 1.0 AND battery voltage > detection_threshold_value_1 Ссылка 1 Простая проверка, какое состояние зажигания или какое напряжение батареи должно присутствовать В таблице С.6 приведен положительный пример напряжения батареи/зажигания «на время». Таблица С.6 — Положительный пример напряжения батареи/зажигания «на время» Ссылка Тип Псевдокод Критерий обнаружения отказа 1 1 1 1 LO-NA LO-NA ignition == 1.0 AND battery voltage > detection_threshold_value_1 for_time >= 300.0 ms AND actuator not commanded (актуатор не включен) Ссылка 1 Состояние зажигания и напряжение аккумулятора должны присутствовать в течение определенного периода времени В таблице С.7 приведен положительный пример опоздания зажигания. Таблица С.7 — Положительный пример опоздания зажигания Ссылка Тип Псевдокод Критерий обнаружения отказа 1 1 1 1 LO-NA LO-NA ignition == 1.0 AND battery voltage > detection_threshold_value_1 delay_time = 200.0 ms AND Ссылка 1 Состояние зажигания и напряжение аккумулятора должны присутствовать в течение определенного периода времени С.3.7 Темы, которые не следует описывать С.3.7.1 Введение С.3.7.1.1 Эксплуатационная готовность ЭБУ Требуется постоянная эксплуатационная готовность ЭБУ, участвующих в обнаружении/устранении отказов. Поэтому нет необходимости перечислять все условия, необходимые для активности ЭБУ. Как правило, она включает в себя активность главного реле. Также для ЭБУ могут быть специфичны другие условия. С.3.7.1.2 Тестовая калибровка Все условия, необходимые для активации тестовых калибровок и коротких замыканий, указывать не нужно. С.3.7.2 Пример эксплуатационной готовности ЭБУ В таблице С.8 приведен отрицательный пример эксплуатационной готовности ЭБУ. Таблица С.8 — Отрицательный пример эксплуатационной готовности ЭБУ > —4 Ссылка Тип Псевдокод ^HsTOF^H Условия разрешения 1 1 Ivjgk == 1.0 AND lv_rly_main == 1.0 AND actuator not commanded (актуатор не включен) Ссылка 1 Здесь показано условие, что главное реле должно быть активным; данное условие не должно быть упомянуто (описано) С.3.8 Правила абстракции С.3.8.1 Введение Сложные программные реализации должны быть описаны в упрощенном виде. Однако принцип физического мониторинга, на котором основано ПО, должен быть включен в описание: - фильтры сглаживания сигнала, другие фильтры и тому подобное не нужно описывать так подробно, как в ПО; - если для обработанного сигнала/переменной имеется точное значение измерения, его следует использовать; - если точное измеренное значение для обработанного сигнала/переменной отсутствует, факты должны быть устно описаны в абстрактном синтаксисе [ABSTRACT-SYNTAX] путем указания текстовой строки (например, «Отфильтрованная частота вращения двигателя»). С.3.8.2 Правило абстракции для VARIABLE-DESCRIPTION В случае сложных алгоритмов ПО автор FXD может принять решение об упрощении описания даже за пределами приведенных выше правил. В этом случае необходимо предоставить дополнительный комментарий с использованием элемента DESC, чтобы проинформировать читателя об упрощении. Рекомендуемый текст для этой информации: «Дополнительная информация предоставляется по запросу». С.3.8.3 Примеры правила абстракции В таблице С.9 приведен положительный пример правила абстракции. Таблица С.9 — Положительный пример правила абстракции Ссылка Тип Псевдокод Критерий обнаружения отказа 1 for_time(Bit_1 == 0.0 1 AND 1 Bit_2 == 0.0, detection_threshold_value_1) Ссылка 1 В абстрактной форме достаточно указать, что условие должно присутствовать в течение периода времени, который может быть определен В таблице С. 10 приведен отрицательный пример правила абстракции. Таблица С. 10 — Отрицательный пример правила абстракции STOP Ссылка Тип Псевдокод Критерий обнаружения отказа 1 1 1 2 for_time(Bit_1 == 0.0 AND delta(Bit_2 == 0.0, detection_threshold_value_1) AND Bit_2 == 0.0 Ссылка 1 2 Указание, что условие не должно изменяться в течение времени калибровки Указание, в каком состоянии должен быть параметр С.3.9 Работа с мониторами силового каскада С.3.9.1 Введение При последующем описании работы с мониторами силового каскада предполагается, что силовой каскад интегрирован в ЭБУ, которые находятся в центре описания FXD, т. е. поставщик ЭБУ имеет подробные знания о конфигурации программного и аппаратного обеспечения установленных компонентов силового каскада. Для управления приводами, работающими в качестве силового каскада, используются интеллектуальные компоненты силового каскада. Эти интеллектуальные компоненты силового каскада независимо выполняют роль мониторов OBDI (замыкание на батарею, замыкание на массу, разомкнутая цепь) и передают результат мониторинга на центральный процессор (CPU) ЭБУ через шину данных в ЭБУ. Пороговые значения мониторинга зависят от следующих аппаратных критериев: - используемый тип силового каскада (для пороговых значений на основе напряжения); - используемый тип силового каскада и конкретного контакта для подключения силового каскада (для пороговых значений на основе тока). Требования к описанию мониторов силового каскада такие же, как и для всех других мониторов. Кроме того, должны быть рассмотрены следующие требования к описанию. В отношении разрешающих условий: - если требуется с технической точки зрения, необходимо указать состояние актуатора (вкл/выкл) (для разграничения между мониторами включенного и выключенного состояния силовых каскадов); - если актуатор управляется с использованием технологии сигналов с широтно-импульсной модуляцией (ШИМ), необходимо указать диапазоны сигналов ШИМ, в пределах которых способен работать соответствующий монитор; - если для работы мониторов используются так называемые «диагностические импульсные генераторы», это должно быть указано. В отношении критериев обнаружения отказов: - если имеются калибруемые метки применения для пороговых значений отказа, они всегда должны указываться. Если поставщик и OEM согласились принять во внимание конкретные аппаратные конфигурации проекта, необходимо также следующее: - индикация пороговых значений конкретного отказа (значения для напряжения/значения для тока); - индикация конкретного типа силового каскада (как примечание в критериях обнаружения отказов). С.3.9.2 Примеры В таблице С. 11 приведены положительные примеры описания мониторинга силового каскада. Таблица С. 11 — Положительные примеры описания мониторинга силового каскада Ссылка Тип Псевдокод Стратегия мониторинга Short to battery (Короткое замыкание на батарею) Критерий обнаружения отказа 1 NOTE «ATIC 435 HW Diagnosis, threshold depends on temperature and battery voltage» («Диагностика ATIC 435 HW, порог зависит от температуры и напряжения аккумулятора») 2 DA-NA Port flap driver output current > (1,0A * within(9.3 from 15.0)) (Выходной ток привода заслонки > (1.0A * в пределах от 9.3 до 15.0)) Разрешающие условия DA-NA Bit_ignition-on ==1 AND 3 DA-NA within (VB, enable_threshold_value_1, enable_threshold_value_2 AND 4 DESC PWM is high(actuator commanded) and rotary valve direction is forward (Высокое значение ШИМ (актуатор включен) и направление вращающегося клапана — вперед) Подтверждение отказа 100.0 ms * debounce_value_1 Ссылка 1 Спецификация используемого типа силового каскада. 2 Информация о конкретных для проекта значениях тока, которые зависят от типа силового каскада и штыревого соединения. 3 Информация о необходимом диапазоне напряжения аккумулятора. 4 Информация о необходимом диапазоне сигнала ШИМ С.3.10 Работа с интеллектуальными модулями С.3.10.1 Введение В данном контексте термин «интеллектуальные модули» относится ко всем компонентам, которые выполняют несколько автоматических мониторов и передают соответствующие результаты мониторинга на ЭВУ, который находится в фокусе описания FXD, через шину связи или дискретные цифровые соединения (например, технология связи SENT). Обычно интеллектуальные модули можно разделить на следующие группы ЭВУ: - диагностические или относящиеся к выбросам ЭВУ (DEC-ECU). Пример —Датчик NOx, датчик твердых частиц; - интеллектуальные устройства. Пример — Датчики SENT. Интеллектуальные модули не обязательно должны быть подключены к ЭБУ, который находится в фокусе описания FXD, через прямой канал связи, т. е. вложенная связь возможна и распространена. На рисунке С.З представлен пример связи. ИКН — система избирательной каталитической нейтрализации отработавших газов Рисунок С.З — Взаимодействие интеллектуальных модулей с ЭБУ Цель: В связи с тем, что поставщик блока управления, который находится в центре внимания описаний FXD, обычно не имеет доступа или имеет ограниченный доступ к информации мониторов, которые работают в подключенных интеллектуальных модулях, возможно только ограниченное описание FXD этих мониторов. Для соответствующего обозначения данных описаний атрибут XML PARTIAL должен быть настроен активным для всех описаний FXD для мониторов интеллектуальными модулями. Минимальные требования к объему описаний FXD для мониторов интеллектуальными модулями: - описание всех операций по устранению отказов, которые происходят в ЭБУ, который находится в центре внимания описаний FXD; - описание всех операций интерпретации отказов, которые происходят в ЭБУ, находящемся в центре внимания описаний FXD; - обозначение этого типа описания с использованием XML-атрибута PARTIAL (DESC-EXTENT). С.3.10.2 Примеры В таблице С. 12 приведен положительный пример описания мониторинга SENT. Таблица С.12 — Положительный пример описания мониторинга SENT Ссылка Тип Псевдокод Стратегия мониторинга Signal check (Проверка сигнала) Критерий обнаружения 1 NOTE «information via SENT» (информация через SENT) отказа 1 LO-NA fast channel data from SENT sensor < min_threshold_value_1 1 OR 1 fast channel data from SENT sensor > max_threshold_value_1 2 AND 2 IF (Code_word_1 ==0 2 THEN 2 getbit (signal_status_nibble_of_SENT_sensor,1) 2 ELSE 2 1.0) Окончание таблицы С. 12 Ссылка Тип Псевдокод Разрешающие условия 3 LO-NA delay_time after ignition-on >= enable_threshold_value_1 Подтверждение отказа 4 10.0 ms * debounce_value_1 Ссылка 1 2 3 4 Информация о внутренней оценке ЭБУ сигнала датчика SENT (оценка по сравнению с внутренними минимальными/максимальными пороговыми значениями ЭБУ). Информация о дополнительных, альтернативных критериях обнаружения (прямая интерпретация обнаружения внутренних отказов датчика SENT). Замечание: Подробности стратегии обнаружения физических отказов (внутри датчика SENT) не упоминаются. Внутреннее разрешающее условие ЭБУ для начала оценки SENT-информации. Замечание: Подробности разрешающих условий (внутри датчика SENT) не упоминаются. Информация об операции подтверждения отказа внутри ЭБУ. Замечание: Подробности стратегии подтверждения (внутри датчика SENT) не упоминаются В таблице СИЗ приведен положительный пример описания подключенного внешнего ЭБУ. Таблица СИЗ — Положительный пример описания подключенного внешнего ЭБУ Ссылка Тип Псевдокод Стратегия мониторинга short to ground (короткое замыкание на землю) Критерий обнаружения отказа 1 NOTE DA-NA -«information via CAN Bus-» (информация через CAN-шину) state_err_taa == 1.0 Условия разрешения 2 LO-NA delay_time after ignition-on >= enable_threshold_value_1 Подтверждение отказа 3 100.0 ms * debounce_value_1 Ссылка 1 2 3 Прямая интерпретация информации об отказах от внешнего ЭБУ (информация, передаваемая по шине данных). Замечание: Подробности стратегии обнаружения физических отказов (внутри внешнего ЭБУ) не упоминаются. Состояние внутреннего разрешения ЭБУ для начала оценки информации шины данных. Замечание: Подробности разрешающих условий (внутри внешнего ЭБУ) не упоминаются. Информация о внутренней процедуре устранения неполадок ЭБУ. Замечание: Детали стратегии подтверждения (внутри внешнего ЭБУ) не упоминаются С.4 Правила подготовки данных В следующих пунктах представлен общий обзор отказов: - С.4.1 — информация, воспринимаемая человеком; - С.4.2 — сокращения; - С.4.3 — заметки; - С.4.4 — определенный подход к подготовке данных; - С.4.5 — «симметрия» диагностических симптомов; - С.4.6 — работа с ингибированием, исключением и валидацией; - С.4.7 — разграничение разрешающих условий; - С.4.8 — заполнение обязательных и необязательных элементов. С.4.1 Информация, воспринимаемая человеком С.4.1.1 Введение Информация, воспринимаемая человеком, относится к терминам «длинное имя» [LONG-NAME], «отображение текста» [TEXT-MAP] и «описание» [DESC]. Ожидается, что этой функции будет присвоено четкое и информативное длинное имя [LONG-NAME] во время разработки ПО. Если длинное имя [LONG-NAME] не является информативным с технической точки зрения, для пояснения должно быть предоставлено информативное описание данных с использованием функции отображения текста [ТЕХТ-МАР]. Кроме того, дополнительный текст и/или дополнительная информация, касающаяся формулы, может быть предоставлена с использованием описания [DESC]. С.4.1.2 Примеры информативного длинного имени, отображения текста, имени и описания данных В таблице С.14 приведен положительный пример информативного длинного имени. Таблица С.14 — Положительный пример информативного длинного имени Ссылка Тип Псевдокод Условия разрешения 1 AND Bit_1 == 0.0 AND ftl_can >= enable_threshold_value_1 Ссылка 1 Длинное имя для ftl_can: уровень в топливном баке В таблице С. 15 приведен отрицательный пример длинного имени и отображения текста. Таблица С. 15 — Отрицательный пример длинного имени и отображения текста STOP Ссылка Тип Псевдокод Условия разрешения 1 AND state_bpa [0] == AD Ссылка 1 LONG-NAME для AD = AD TEXT-MAP для AD: Adaptation (адаптация) DESCRIPTION: неприменимо Хотя для AD предусмотрены как длинное имя [LONG-NAME], так и текстовое отображение [ТЕХТ-МАР], ни одно из представленных данных не дает объяснения того, что подразумевается под адаптацией В таблице С. 16 приведен положительный пример имени данных и описания. Таблица С.16 — Положительный пример имени данных и описания Ссылка Тип Псевдокод Критерий обнаружения отказа 1 1 DA-NA DESC Bit_cat_purge_act == 0.0 Bit_cat_purge_act Очистка катализатора активна, если активен какой-либо из двух катализаторов (предварительный катализатор или основной катализатор). Общие условия ингибирования продувки катализатора: - массовый расход воздуха больше, чем threshold_air_mass; - число оборотов двигателя выше, чем threshold_engine_speed; - температура охлаждающей жидкости двигателя ниже, чем threshold_ECT; двигатель не работает или рабочий режим двигателя — торможение двигателем, подача топлива ограничивается через Cod ewort_cat_p urge Расчет: measurement_air_mass >= threshold_air_mass or engine_speed >= threshold_engine_speed or ECT <= threshold_ECT or Bit_engine_stop == 1 or Bit_trailing_throttle == 1 Ссылка 1 Бит с дополнительным описанием С.4.2 Сокращения С.4.2.1 Введение Следует избегать сокращений, которые не соответствуют стандарту SAE (например, сокращения, применяемые только внутри компании). Если эти сокращения используются, то они должны быть объяснены. Например, это можно сделать, используя отображение текста функций FXD [TEXT-MAP] или описание [DESC]. С.4.2.2 Примеры сокращений Аббревиатура «TDC» (Верхняя мертвая точка). В таблице С. 17 приведен положительный пример сокращения. Таблица С. 17 — Положительный пример сокращения Ссылка Тип Псевдокод Условия разрешения 1 DA-NA LO-NA Code_word_1 == 0.0 Diagnosis TDC [Top Dead Center] counting mode: counting all TDC (=0) or only diagnosed (=1) (Режим расчета диагностики TDC [Верхняя мертвая точка]: расчет всех TDC (=0) или только продиагностированных (=1)) Ссылка 1 В длинном имени [LONG-NAME], отображении текста [TEXT-MAP] и описании [DESC] аббревиатура должна быть полностью записана в [ ] В таблице С.18 приведен отрицательный пример сокращения. Таблица С. 18 — Отрицательный пример сокращения Ссылка Тип Псевдокод Условия разрешения 1 DA-NA LO-NA Code_word_1 == 0.0 Diagnosis TDC counting mode: counting all TDC (=0) or only diagnosed (=1) (Режим расчета диагностики TDC: расчет всех TDC (=0) или только про-диагностированных (=1)) Ссылка 1 В данном случае объяснение аббревиатуры отсутствует в текстовом отображении (TEXT-MAP) и описании (DESC) С.4.3 Заметки С.4.3.1 Введение Цель заметки — предоставить простую возможность объяснить последующие условия коротким словесным выражением. Кроме того, заметки должны быть информативными и интерпретируемыми. Описания всегда должны соответствовать последующим описаниям. С.4.3.2 Пример несоответствующей заметки В таблице С. 19 приведен пример несоответствующей заметки. Таблица С. 19 — Пример несоответствующей заметки Ссылка Тип Псевдокод Условия разрешения AND 1 -«inhibition due to instable engine operating point-» («ингибирование из-за нестабильной работы двигателя») 2 measurement_value_1 > enable_threshold_value_1 2 AND for_time 2 measurement_value_2 > enable_threshold_vaue_2 Ссылка 1 В соответствии с заметкой это ингибирование. 2 Предоставленная информация является разрешающими условиями С.4.4 Определенный подход к подготовке данных С.4.4.1 Введение При представлении ПО подход заключается в том, чтобы, когда это возможно, отрицательные этапы ПО были проиллюстрированы в позитивном ключе. Кроме того, доступное ПО должно быть соответственно абстрагировано. Примечание — Не следует описывать условия прерывания/остановки (например, сброс триггера не требуется, если только этот сброс не представляет собой автономное состояние). С.4.4.2 Примеры описания с положительной логикой На рисунке С.4 показан положительный пример описания с положительной логикой. Рисунок С.4 — Положительный пример описания с положительной логикой На рисунке С.5 показан отрицательный пример точного описания в соответствии с ПО. Рисунок С.5 — Отрицательный пример точного описания в соответствии с ПО С.4.5 «Симметрия» диагностических симптомов С.4.5.1 Введение Как правило, диагностический монитор является «симметричным», если симптом отказа соответствует следующим критериям: - идентичные разрешающие условия для проверки наличия и отсутствия назначенной ошибки, - для обнаружения исправного состояния, полностью противоположного (логическое отрицание) критерию обнаружения отказа (например, отказ обнаруживается, если var_1> threshold_1, а исправное состояние обнаруживается при var_1 <= threshold_1), - идентичные условия подтверждения для ошибки и исправного состояния. Далее перечислены правила описания, относящиеся к симметрии монитора. С.4.5.2 Описание разрешающих условий Симметричный пример Если физические разрешающие условия идентичны для обнаружения отказов и для обнаружения исправного состояния, элемент ENABLE-CONDITIONS должен быть заполнен, а элемент OK-ENABLE-CONDITIONS должен быть создан без содержимого, но атрибут xsi:nil установлен в «true». Асимметричный пример Оба элемента должны быть заполнены полностью (т. е. в обоих элементах должны содержаться общие части). С.4.5.3 Описание критерия обнаружения Симметричный пример Если критерий обнаружения отказа является полной противоположностью (логическое отрицание) критериям обнаружения исправного состояния, элемент FAULT-DETECTION-CRITERIA должен быть заполнен, а элемент ОК-DETECTION должен быть создан без содержимого, но атрибут xsi:nil установлен в «true». Асимметричный пример Оба элемента должны быть заполнены полностью (т. е. в обоих элементах должны содержаться общие части). С.4.5.4 Описание подтверждения отказа Симметричный пример Если подтверждение идентично подтверждению отказа, элемент FAULT-DEBOUNCE должен быть заполнен, а элемент OK-DEBOUNCE должен быть создан без содержимого, но для атрибута xsknil установлено значение «true». Асимметричный пример Оба элемента должны быть заполнены полностью (т. е. в обоих элементах должны содержаться общие части). Ниже приведены примеры описания асимметричной и симметричной диагностики. В таблице С.20 приведен положительный пример описания асимметричной диагностики. Таблица С.20 — Положительный пример описания асимметричной диагностики Ссылка Тип Псевдокод Критерий обнаружения отказа 1 measurement_value_1 >= detection_threshold_value_1 Условия разрешения 1 enable_value_1 >= enable_threshold_value_1 1 AND 1 enable_value_2 > enable_threshold_value_2 Подтверждение 1 100 ms * threshold_value_1 Критерий обнаружения исправного 2 measurement_value_2 < detection_threshold_value_2 состояния Окончание таблицы С. 20 Ссылка Тип Псевдокод Условия разрешения исправного состояния 2 2 2 2 2 2 2 enable_value_1 < enable_threshold_value_1 AND IF(Code_word_1 == 1 THEN enable_status_2 == condition_2_1 ELSE enable_bit_4 == bit_status_5_1) Подтверждение исправного состояния 2 500 ms Ссылка 1 2 Информация для обнаружения отказа. Информация для устранения отказа для асимметричного монитора В таблице С.21 приведен положительный пример описания симметричной диагностики. Таблица С.21 — Положительный пример описания симметричной диагностики Ссылка Тип Псевдокод Критерий обнаружения отказа 1 measurement_value_1 >= detection_threshold_value_1 Условия разрешения 1 enable_value_1 >= enable_threshold_value_1 1 AND 1 enable_value_2 > enable_threshold_value_2 Подтверждение 1 100 ms * threshold_value_1 Критерий обнаружения исправного состояния 2 Условия разрешения исправного состояния 2 Подтверждение исправного состояния 2 Ссылка 1 Информация для обнаружения отказа. 2 Элемент существует с пустым содержимым и атрибутом xsi:nil = ’’true” В таблице С.22 приведен положительный пример описания частично асимметричной диагностики. Таблица С.22 — Положительный пример описания частично асимметричной диагностики Ссылка Тип Псевдокод Критерий обнаружения 1 measurement_value_1 >= detection_threshold_value_1 отказа Условия разрешения 1 enable_value_1 >= enable_threshold_value_1 1 AND 1 enable_value_2 > enable_threshold_value_2 Подтверждение 1 100 ms * threshold_value_1 Окончание таблицы С. 22 Ссылка Тип Псевдокод Критерий обнаружения исправного состояния 2 Условия разрешения исправного состояния 3 3 3 3 3 3 3 enable_value_1 < enable_threshold_value_1 AND IF(Code_word_1 == 1 THEN enable_status_2 == condition_2_1 ELSE enable_bit_4 == bit_status_5_1) Подтверждение исправного состояния 3 500 ms Ссылка 1 2 3 Информация для обнаружения отказа. Информация для устранения отказа в случае симметрии: Элемент существует с пустым содержимым и атрибутом xsi:niI = ’’true”. Информация для устранения отказа в случае асимметрии В таблице С.23 приведен отрицательный пример описания частично асимметричной диагностики. Таблица С.23 — Отрицательный пример описания частично асимметричной диагностики STOP Ссылка Тип Псевдокод Критерий обнаружения отказа 1 measurement_value_1 >= detection_threshold_value_1 Условия разрешения 1 1 1 enable_value_1 >= enable_threshold_value_1 AND enable_value_2 > enable_threshold_value_2 Подтверждение 1 100 ms * threshold_value_1 Критерий обнаружения исправного состояния 2 measurement_value_1 < detection_threshold_value_1 Условия разрешения исправного состояния 3 3 3 3 3 3 3 enable_value_1 < enable_threshold_value_1 AND IF(Code_word_1 == 1 THEN enable_status_2 == condition_2_1 ELSE enable_bit_4 == bit_status_5_1) Подтверждение исправного состояния 3 500 ms Ссылка 1 2 3 Информация для обнаружения отказа. Информация для устранения отказа в случае симметрии: Элемент существует с пустым содержимым и атрибутом xsknil = ’’true”. Информация для устранения отказа в случае асимметрии С.4.6 Работа с ингибированием, исключением и валидацией С.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). Это сделано намеренно, поскольку ингибирование представляет собой особый механизм запрещения функциональности ПО. С.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». Пример — Монитор катализатора ожидает сигнала исправного состояния от датчика кислорода. С.4.6.3 Ингибирование с помощью исключения Запрещение с помощью исключения используется всякий раз, когда две функции или два монитора не могут выполняться или могут не выполняться одновременно. Условия запрета с помощью исключения должны быть указаны в соответствующем элементе. (/FAULT-SYMPTOM-EXCH-DESC/FAULT-SYMPTOMS/FAULT-SYMPTOM/INHIBITION/BY-FUNCTION/ EXCLUSIONS/EXCLUSION). С.4.6.4 Примеры ингибирования, исключения и валидации В таблице С.24 приведен отрицательный пример ингибирования. Таблица С.24 — Отрицательный пример ингибирования Ссылка Тип Псевдокод > < FAULT-DETECTION_1 Условия разрешения 1 Bit_1 == 1.0 OR Bit_2 == 1.0 AND state_cp == MIN_PURGE AND faultbit_1 == 0.0 Ссылка 1 Это запрещение по другому симптому (например, коду отказа). Данный тип запрещения должен указываться в элементе «INHIBITION/BY-SYMPTOMS», а не в элементе «ENABLE-CONDITIONS» В таблице С.25 приведен отрицательный пример исключения. Таблица С.25 — Отрицательный пример исключения Ссылка Тип Псевдокод FAULT-DETECTION_1 Условия разрешения 1 Bit_1 == 1.0 OR Bit_2 == 1.0 AND state_cp == MIN_PURGE AND Monitor_B = not active Ссылка 1 Данная команда запрещает монитор, завершивший работу. Этот тип запрета должен указываться в элементе «INHIBITION/BY-FUNCTION», а не в элементе «ENABLE-CONDITIONS» В таблице С.26 приведен отрицательный пример валидации. Таблица С.26 — Отрицательный пример валидации STOP Ссылка Тип Псевдокод FAULT-DETECTION_1 Условия разрешения 1 Bit_1 == 1.0 OR Bit_2 == 1.0 AND state_cp == MIN_PURGE AND Monitor_B = tested Ссылка 1 Данный запрет активен, пока успешно не запустится монитор В. Этот тип запрета должен указываться в элементе «INHIBITION/BY-SYMPTOM», а не в элементе «ENABLE-CONDITIONS» С.4.7 Разграничение разрешающих условий С.4.7.1 Введение Если разрешающие условия являются обширными и/или сложными, последовательно перечислять эти разрешающие условия часто бессмысленно. Это затрудняет или даже делает невозможным интерпретацию временных, параллельных или связанных последовательностей. Поэтому для упрощения интерпретации разрешающих условий имеет смысл сгруппировать связанные разрешающие условия и дать им информативные заголовки. Примеры таких заголовков: - общее разрешающее условие; - монитор условий входа; - диапазон измерений: - начало измерения; - условия для диапазона измерения; - конец измерения; - таймер подтверждения; С.4.7.2 Пример дифференциации разрешающих условий В таблице С.27 приведен положительный пример № 1 дифференциации разрешающих условий. Таблица С.27 — Положительный пример № 1 дифференциации разрешающих условий Ссылка Тип Псевдокод Разрешающие условия LO-NA Phase 1: Monitor Entry Conditions (Этап 1: Условия разрешения монитора) conventional conversion efficiency check == 1.0 (обычная проверка эффективности преобразования == 1.0) NOx sensor == ready SCR catalyst temperature == xx...yy OR Phase 2: urea overdosing (Этап 2: передозировка мочевины) LO-NA LO-NA LO-NA overdosing urea system and evaluation of current efficiency (передозировка мочевины в системе и оценка текущей эффективности) > threshold_value_1 AND Phase 3: urea discharging (Этап 3: сброс мочевины) urea dosing == 0.0 (дозировка мочевины == 0.0) AND Phase 4: evaluation of phase 2 and phase 3 (Этап 4: оценка этапов 2 и 3) calculation of average efficiency during phase 2 and 3 ==1.0 (расчет средней эффективности на этапах 2 и 3 == 1.0) В таблице С.28 приведен положительный пример № 2 дифференциации разрешающих условий. Таблица С.28 — Положительный пример № 2 дифференциации разрешающих условий Ссылка Тип Псевдокод Разрешающие условия Monitor Entry Conditions: (Условия разрешения монитора) engine speed > enable_threshold_value_1 injection quantity <= enable_threshold_value_2 AND Debounce Timer: (таймер подтверждения) Accumulated debounce time of monitor entry conditions >= threshold_value_3 (Накопленное время подтверждения разрешающих условий монитора) >= threshold_value_3 AND Debounce Timer Conditions: (Условия таймера подтверждения): Start of debounce timer: (Начало работы таймера подтверждения) Monitor Entry Conditions fulfilled >= threshold_value_4 (Разрешающие условия монитора выполнены) >= threshold_value_4 С.4.8 Заполнение обязательных и необязательных элементов С.4.8.1 Введение Схема FXD содержит как обязательные, так и необязательные теги. Такое разделение позволяет быстро идентифицировать элементы, которые не были заполнены по ошибке. Обязательный элемент: - как правило, обязательные элементы должны быть заполнены всегда. Исключения: - элемент FAULT-DETECTION-CRITERIA: - если информация не может быть предоставлена, поскольку у симптома нет критериев обнаружения отказов, это должно быть объяснено с помощью свободного текста. Все остальные обязательные элементы: - если информация не может быть предоставлена, потому что соответствующий симптом не поддерживает эту функцию, атрибут xsi:nil должен быть установлен в «true». Необязательный элемент: - как правило, необязательные элементы всегда будут заполнены, если соответствующая функция поддерживается описываемым симптомом. С.4.8.2 Примеры обязательного поля В таблице С.29 приведен положительный пример обязательного поля. Таблица С.29 — Положительный пример обязательного поля Ссылка Тип Псевдокод FAULT-DETECTION_1 Стратегия мониторинга Short to battery/open circuit (Короткое замыкание на батарею/разрыв цепи) Критерий обнаружения отказа measurement_value_1 > detection_threshold_value_1 Разрешающие условия 1 true Подтверждение отказа 40.0 ms * threshold_value_2 Окончание таблицы С. 29 Ссылка Тип Псевдокод Ссылка 1 Данное утверждение четко определяет, что разрешающие условия недоступны или что они не должны быть указаны В таблице С.30 приведен отрицательный пример обязательного поля. Таблица С.30 — Отрицательный пример обязательного поля Ссылка Тип Псевдокод FAULT-DETECTION_1 Стратегия мониторинга Short to battery/open circuit (короткое замыкание на батарею/разрыв цепи) Критерий обнаружения отказа measurement_value_1 > detection_threshold_value_1 Разрешающие условия 1 Подтверждение отказа 40.0 ms * threshold_value_2 Ссылка 1 Отсутствует псевдокод в обязательном поле. Невозможно определить, отсутствуют ли разрешающие условия (или отсутствуют условия, которые должны быть указаны) или поле не заполнено по ошибке С.4.9 Условия запрета с использованием системных констант С.4.9.1 Введение Условиями запрета можно управлять с помощью нескольких механизмов в ЭВУ, находящемся в центре внимания описания FXD. Следующая спецификация относится только к управлению условиями запрета с помощью системных констант. Можно наблюдать следующие константы системы. Системная константа 1: Системная константа определяет, существуют или нет функции или частичные функции с условиями запрета в ПО (вариантное управление). Системная константа 2: Системная константа сама управляет условием запрета или составляет условие запрета. Эти системные константы (характеристики 1 и 2) могут использоваться как для категории DISABLE-FULLY, так и для категории DISABLE-REPORT-ONLY. Цель. Системная константа 1: - в элементе CONFIGURATION должны быть указаны соответствующие системные константы; в элементе DISABLE-FULLY или элементе DISABLE-REPORT-ONLY должны быть указаны условия, которые управляют состоянием запрета через указанную системную константу; - информация не указывается при отсутствии условий запрета. Системная константа 2: - в элементе CONFIGURATION должны быть указаны соответствующие системные константы; в элементе DISABLE-FULLY или элементе DISABLE-REPORT-ONLY должен быть указан специфический для проекта результат оценки состояния системной константы; - информация не указывается при отсутствии условий запрета. С.4.9.2 Примеры В таблице С.31 приведен положительный пример условия запрета. Таблица С.31 — Положительный пример условия запрета (характеристика 1) Ссылка Тип Псевдокод Конфигурация 1 System_constant_1 = 1.0 Только отчет о запрете 2 code_word_1 == 1 Ссылка 1 2 Указание всех системных констант, которые необходимо учитывать в описании FXD. Эти системные константы могут влиять на условия запрета (например, использование кодовых слов) в зависимости от их характеристик. Индикация всех возможных условий запрета. Каждое указанное условие запрета может зависеть от системной константы с ее характеристиками В таблице С.32 приведен положительный пример условия запрета. Таблица С.32 — Положительный пример условия запрета (характеристика 2) Ссылка Тип Псевдокод Конфигурация 1 System_constant_1 = 1.0 Полный запрет 2 true Ссылка 1 2 Индикация системной константы, которая составляет условие запрета. Индикация конкретного для проекта результата постоянного состояния системы. Возможные результаты: - истина (true) (интерпретация: условие запрета активно); - ложь (false) (интерпретация: условие запрета неактивно) С.5 Правила представления С.5.1 Введение В следующих пунктах представлено содержание раздела о представлении информации: - С.5.2 — системные константы и параметры конфигурации; - С.5.3 — биты, состояния и комплексные значения; - С.5.4 — условные операторы и ветвления; - С.5.5 — битовые маски; - С.5.6 — представление формул; - С.5.7 — контрольные опции после калибровки; - С.5.8 — приводы и датчики; - С.5.9 — функционально равные условия; - С.5.10 — работа со стратегиями обнаружения отказов; - С.5.11 — работа с критериями устранения отказов в случае нескольких стратегий; - С.5.12 — последовательность описания для нескольких записей в отношении нескольких выпусков; - С.5.13 — порядок описания для функциональных записей; - С.5.14 — XOR-информация. С.5.2 Системные константы и параметры конфигурации С.5.2.1 Введение Когда описание симптомов мониторинга зависит от системных констант и/или параметров конфигурации, оно должно составляться исключительно для конкретной системной константы и/или настройки параметров конфигурации, которая зафиксирована в программной сборке описательного проекта. Эти системные константы/параметры конфигурации должны быть соответственно указаны в элементе «CONFIGURATION». С.5.2.2 Примеры системной константы В таблице С.33 приведен положительный пример системной константы. Таблица С.33 — Положительный пример системной константы Ссылка Тип Псевдокод Конфигурация 1 System_constant_1 = 1 System_constant_2 = 1 System_constant_3 = 1 Ссылка 1 Это точные настройки системной константы. Соответствующее описание симптомов описано в соответствии со спецификациями системных констант, приведенными здесь В таблице С.34 приведен отрицательный пример № 1 системной константы. Таблица С.34 — Отрицательный пример № 1 системной константы Ссылка Тип Псевдокод Конфигурация 1 Описание 2 DESC Bitmask_A[0] 2 Bitmask_A is indicating in which offset adaption field learning is active. 2 The number of offset adaption fields is set by system_constant_1 Ссылка 1 Информация о существующих спецификациях системных констант недоступна. 2 Описание [DESC], показанное выше, указывает на зависимость от системной константы. Однако системная константа не указана в обозначенном элементе В таблице С.35 приведен отрицательный пример № 2 системной константы. Таблица С.35 — Отрицательный пример № 2 системной константы Ссылка Тип Псевдокод Конфигурация 2 System_constant_1 = 1 2 System_constant_2 = 1 2 System_constant_3 = 1 Критерий обнаружения «only used if three used pressure sensors» отказа 1 («используется только если используются 3 датчика давления») 1.0 AND Bit_1 == 1.0 AND 1 1.0 AND Bit_2 == 1.0 AND 1 1.0 AND Bit_3 == 1.0 Окончание таблицы С. 35 Ссылка Тип Псевдокод Ссылка 1 Информация о точных настройках системной константы, которые не могут быть идентифицированы как таковые (отсутствует декларация). Кроме того, информация о системных константах должна предоставляться исключительно в элементе «CONFIGURATION» С.5.3 Биты, состояния и комплексные значения С.5.3.1 Введение Определения Биты: - биты могут иметь только два состояния (== 0.0 или == 1.0). Состояния: - состояния могут быть представлены с использованием разных условий. Комплексные значения: - в комплексных значениях описываются тщательно рассчитанные или смоделированные значения в случаях, когда физические значения, на которых они основаны, и их содержание не могут быть легко определены. Цель Если биты, состояния или комплексные значения, используемые в ПО, релевантны для описания, они должны быть сопоставлены с базовыми физическими условиями с использованием элемента ABSTRACT-SYNTAX. Глубина разрешения зависит от требований OEM и должна быть согласована соответствующим образом. Исходный, неразрешенный бит, само состояние или комплексное значение должны быть предоставлены с помощью оператора примечания до его разрешения. Примеры 1 Если бит, состояние или комплексное значение могут быть преобразованы в дополнительные биты, и/или состояния, и/или комплексные значения, последние также должны быть преобразованы в их физические условия. 2 В некоторых случаях OEM и поставщик документации FXD могут согласиться с тем, что не имеет смысла дополнительно разрешать биты, и/или состояния, и/или сложные значения из-за их физической сложности. В этих случаях эти биты, и/или состояния, и/или комплексные значения должны быть описаны сложным и информативным способом в прозе с использованием описаний [DESC]. Далее приведены примеры комплексного значения и бита с дополнительным описанием и без него. В таблице С.36 приведен положительный пример комплексного значения. Таблица С.36 — Положительный пример комплексного значения Ссылка Тип Псевдокод FAULT-DETECTION_1 Разрешающие условия NOTE P-part > characteristic_curve_4 of the calculation IF (max(abs(max(value(characteristic_curve_1)))) * max(value(characteristic_curve_2)) * * max(value(characteristic_map_1)) * max(value(characteristic_curve_3))) > enable_threshold_ value_1 THEN measurement_value_1 < enable_threshold_value_1 ELSE true В таблице С.37 приведен положительный пример бита с дополнительным описанием. Таблица С.37 — Положительный пример бита с дополнительным описанием Ссылка Тип Псевдокод Критерий обнаружения отказа 1 DA-NA lv_cat_purge_act [0] == 0.0 1 DESC lv_cat_purge_act [0] Cat purge is active if any of the two catalysts (pre catalyst or main catalyst) purges is active [Очистка катализатора активна, если активен какой-либо из двух катализаторов (предварительный катализатор или основной катализатор)]. Common inhibition conditions for catalyst purge: (Общие условия ингибирования продувки катализатора:) air mass flow greater than C_MAF_MAX_CAT_PURGE engine speed greater than C_N_MAX_CAT_PURGE Ссылка 1 Бит с дополнительным описанием В таблице С.38 приведен отрицательный пример бита без дополнительного описания. Таблица С.38 — Отрицательный пример бита без дополнительного описания Ссылка Тип Псевдокод Критерий обнаружения отказа 1 DA-NA Bit_2 [0] == 0.0 1 DESC Ссылка 1 Бит без дополнительного описания На рисунке С.6 показан положительный пример разрешения. Рисунок С.6 — Положительный пример разрешения С.5.4 Условные операторы и ветвления С.5.4.1 Введение Условные операторы и/или ветвления позволяют реализовать различные стратегии мониторинга и/или спецификации мониторинга посредством калибровки (например, с помощью кодового слова). Все условные утверждения и/или разветвления, которые могут быть установлены с помощью калибровки и которые влияют на мониторинг описываемого симптома, должны быть описаны полностью. Условные операторы и/или ветвления всегда должны предоставляться в едином формате с использованием оператора «IF-THEN-ELSE». С.5.4.2 Примеры условного оператора и ветвления В таблице С.39 приведен положительный пример условного оператора. Таблица С.39 — Положительный пример условного оператора Ссылка Тип Псевдокод SLOW_DETECTION Разрешающие условия 1 2 2 3 3 AND IF(code_word_1 == 0.0 THEN Bit_catalyst_heating == 0.0 ELSE true) AND IF Ссылка 1 2 3 Условие в виде кодового слова. Состояние. Индикация обхода В таблице С.40 приведен положительный пример ветвления. Таблица С.40 — Положительный пример ветвления Ссылка Тип Псевдокод FAULT_DETECTION_1 Критерий обнаружения 1 IF (code_word_1 == 0.0 отказа THEN 2 measurement_value_1 > detection_threshold_value_1 2 ELSE 2 measurement_value_1 > detection_threshold_value_2) Ссылка 1 Условие в виде кодового слова. 2 Ветвление С.5.5 Битовые маски С.5.5.1 Введение Определения Битовые маски относятся к конструкциям, в которых отдельные биты байта используются для различных разрешающих условий. Точные условия могут быть «скрыты» за отдельными битами битовой маски. Битовые маски должны быть представлены в едином, непрерывном, интерпретируемом формате, который можно прочитать с помощью инструмента. Основная структура должна быть построена с использованием оператора «IF-THEN-EL.SE». В пределах этой структуры должны быть предусмотрены различные условия для соответствующей позиции бита. Метка битовой маски должна указываться оператором «getbit» и битовой позицией, которая отвечает за отдельные условия. Начальное значение приращения (битовая позиция) всегда имеет значение «0». Оператор «getbit» должен использоваться исключительно с операторами «TRUE» или «FALSE». Путь THEN всегда должен присваиваться оператору «TRUE», а путь ELSE всегда должен присваиваться оператору «FALSE». С.5.5.2 Примеры битовых масок В таблице С.41 приведен положительный пример битовых масок. Таблица С.41 — Положительный пример битовых масок Ссылка Тип Псевдокод FAULT_DETECTION_1 Разрешающие условия 1 1 1 IF(getbit(enable_threshold_value_1,0) THEN Bit_catalyst_heating == 0.0 ELSE 1.0) AND IF(getbit(enable_threshold_value_1, 1) THEN Bit_warmup == 0.0 ELSE 1.0) AND IF(getbit(enable_threshold_value_1,2) THEN Bit_lambda_controller == 0.0 ELSE 1.0) 1 AND IF(getbit(enable_threshold_value_1,7) THEN Bit_catpurge == 0.0 ELSE 1.0) Ссылка 1 Однозначное распределение битов 0 — 7 В таблице С.42 приведен отрицательный пример битовых масок. Таблица С.42 — Отрицательный пример битовых масок Ссылка Тип Псевдокод FAULT_DETECTION_1 Разрешающие условия 1 IF(enable_threshold_value_1 & 1.0 == 1.0 THEN 1 1 1.0 ELSE Bit_catalyst_heating == 0.0 AND IF(enable_threshold_value_1 & 2.0 == 2.0 THEN 1.0 ELSE Bit_warmup == 0.0) AND IF(enable_threshold_value_1 & 4.0 == 4.0 THEN 1.0 ELSE Bit_lambda_controller == 0.0) 1 AND IF(enable_threshold_value_1 & 128.0 == 128.0 THEN 1.0 ELSE Bit_cat_purge == 0.0) Ссылка 1 Интерпретация описания 8-битного значения затруднена В таблице С.43 приведен отрицательный пример битовых масок с использованием побитового оператора. Таблица С.43 — Отрицательный пример битовых масок с использованием побитового оператора STOP Ссылка Тип Псевдокод Разрешающие условия 1 measurement_value_1 >= enable_threshold_value_1 AND Bitmask_1 & enable_threshold_value_2 == 1.0 OR Ссылка 1 Описание с затрудненным пониманием С.5.6 Представление формул С.5.6.1 Введение При создании документации обычно используется следующая структура описания: - измеренное количество/оператор/калиброванное значение. Пример — Число оборотов двигателя > 2000 об/мин. Когда структура описания отклоняется от программной реализации, реализованное ПО должно быть абстрагировано таким образом, чтобы для представления могла использоваться типичная структура. С.5.6.2 Примеры представления формул В таблице С.44 приведен положительный пример представления формул. Таблица С.44 — Положительный пример представления формул Ссылка Тип Псевдокод FAULT_DETECTION_1 Разрешающие условия (measurement_value_1 >= (enable_threshold_value_1 + enable_threshold_value_2) OR (measurement_value_1 <= (enable_threshold_value_1 + (-1.0* enable_threshold_value_2)) Ссылка 1 Четкое различие между измеренным значением и пороговым значением В таблице С.45 приведен отрицательный пример представления формул. Таблица С.45 — Отрицательный пример представления формул s —X Ссылка Тип Псевдокод '-------' FAULT_DETECTION_1 Разрешающие условия 1 ABS (Measurement_value_1 + (-1.0 * enable_threshold_ value_1))>= enable_threshold_value_2 AND Ссылка 1 Представление является сложным, поскольку значение измерения и пороговое значение объединены С.5.7 Контрольные опции после калибровки С.5.7.1 Введение Если описание симптома мониторинга зависит от контрольной опции после калибровки, должны быть перечислены все возможные варианты. Описание всегда должно предоставляться в едином формате в разрешающих условиях [ENABLE-CONDITIONS] и критериях обнаружения отказов [FAULT-DETECTION-CRITERIA]. Контрольная опция после калибровки должна быть представлена с помощью оператора «IF - THEN - ELSE». Данные контрольные опции после калибровки должны маркироваться с использованием соответствующего длинного имени [LONGNAME], описания [DESC] или примечания. Примеры контрольных опций после калибровки: - автоматические процессы обучения; - вариант кодирования в конце линии/сервиса. С.5.7.2 Примеры контрольных опций после калибровки В таблице С.46 приведен отрицательный пример № 1 опций после калибровки. Таблица С.46 — Отрицательный пример № 1 контрольных опций после калибровки 7 Ссылка Тип Псевдокод ^■stopM > < Конфигурация 1 LO-NA IDX_VAR_EMI system_constant_1 Ссылка 1 Контрольная опция после калибровки не должна быть указана в конфигурации В таблице С.47 приведен отрицательный пример № 2 контрольных опций после калибровки. Таблица С.47 — Отрицательный пример № 2 контрольных опций после калибровки STOP Ссылка Тип Псевдокод Разрешающие условия 1 1 DA-NA LO-NA THEN mis_sum_b > IF idx_var_emi == 0.0 Index of selected emission variants == 0.0 THEN enable_threshold_value_1 2 DESC Ссылка 1 2 Предоставленная информация относится к контрольной опции после калибровки. Даже если принять во внимание соответствующее длинное имя [LONG-NAME], этот факт явно не распознается. Отсутствует описание или расшифровка вариантов эмиссии С.5.8 Приводы и датчики С.5.8.1 Введение Можно предположить, что должен быть установлен некий компонент (привод/датчик), подлежащий монито рингу. По этой причине информация о месте установки не должна предоставляться в качестве критерия разрешения в соответствующем компонентном мониторе. С другой стороны, всегда должны предоставляться условия, запрашивающие активность компонента, подлежащего мониторингу. С.5.8.2 Пример приводов и датчиков В таблице С.48 приведен отрицательный пример, относящийся к приводам и датчикам. Таблица С.48 — Отрицательный пример, относящийся к приводам и датчикам Ссылка Тип Псевдокод FAULT-DETECTION_1 Разрешающие условия 1 1 Bit_barometric_pressure == 1.0 AND Bit_manifold_pressure == 1.0 AND Ссылка 1 Факт наличия перечисленных датчиков/исполнительных механизмов не должен указываться в разрешающих условиях С.5.9 Функционально равные условия С.5.9.1 Введение Функционально равные условия (например, избыточные условия, условия, которые исключают друг друга, подмножества и т. п.) не должны предоставляться несколько раз, если одновременное указание этого условия не дает никакой информации для создания сводной таблицы и/или документации по обслуживанию клиентов. Описания симптомов, которые имеют частоту мониторинга «Один раз за ездовой цикл (DCY)», не нуждаются в дополнительном указании, что монитор не должен работать в этом DCY во включенном состоянии [ENABLE-CONDITION], С.5.9.2 Примеры разрешающих условий для функционально равных условий В таблице С.49 приведен отрицательный пример № 1 разрешающих условий для функционально равных условий. Таблица С.49 — Отрицательный пример № 1 разрешающих условий для функционально равных условий STOP Ссылка Тип Псевдокод FAULT-DETECTION_1 Разрешающие условия 1 1 2 2 Bit_1 == 1.0 AND measurement_value_engine_speed > enable_threshold_value_1 AND measurement_value_2 > enable_threshold_value_2 AND Bit_engine_stop == 0.0 Ссылка 1 2 Приведенное здесь значение является подмножеством условия, указанного в п. 2. Это условие всегда выполняется, когда выполняется условие 1. Таким образом, оно является избыточным для условия 1 и может быть опущено В таблице С.50 приведен отрицательный пример № 2 разрешающих условий для функционально равных условий. Таблица С.50 — Отрицательный пример № 2 разрешающих условий для функционально равных условий STOP Ссылка Тип Псевдокод OK-DETECTION Разрешающие условия 1 1 2 2 AND Bit_1 == 1.0 AND Bit_engine_running == 1.0 AND Bit_engine_stop == 0.0 Ссылка 1 2 Данный оператор функционально равен условию 2. В этом случае «активный» случай должен быть сохранен. Это условие всегда выполняется, когда выполняется условие 1. Таким образом, оно является избыточным для условия 1 и может быть опущено С.5.10 Работа со стратегиями обнаружения отказов С.5.10.1 Введение Когда в описываемом ПО есть симптомы, которые имеют несколько стратегий обнаружения отказов [FAULTDETECTION], различные стратегии обнаружения отказов, включая соответствующую информацию (например, разрешающие условия), должны быть представлены как отдельные записи [FAULT-DETECTION] обнаружения отказов в базе симптомов отказов [FAULT-SYMPTOM-BASE] соответствующего симптома отказа. С.5.10.2 Примеры симптомов отказа с несколькими стратегиями В таблице С.51 приведен положительный пример симптома отказа с несколькими стратегиями. Таблица С.51 — Положительный пример симптома отказа с несколькими стратегиями Ссылка Тип Псевдокод Symptom 1 / FAULT-DETECTION_Part_load Критерий обнаружения отказа 1 measurement_value_1 >= detection_threshold_value_1 Разрешающие условия Symptom 1 / FAULT-DETECTION_Full_load Критерий обнаружения отказа 2 measurement_value_2 >= detection_threshold_value_2 2 OR 2 measurement_value_3 >= detection_threshold_value_3 Разрешающие условия Ссылка 1 Критерий симптома отказа для стратегии мониторинга 1. 2 Критерий симптома отказа для стратегии мониторинга 2 В таблице С.52 приведен отрицательный пример симптома отказа с несколькими стратегиями. Таблица С.52 — Отрицательный пример симптома отказа с несколькими стратегиями Ссылка Тип Псевдокод Критерий обнаружения 1 Bit_1 == 1 отказа 1 AND 1 measurement_value_1 >= detection_threshold_value_1 1 AND 1 code_word_1 == 1 OR 2 Bit_2 == 1 2 AND 2 measurement value 2 >= detection threshold value 2 2 AND 2 code_word_2 == 1 Разрешающие условия Ссылка 1 Критерий симптома отказа для FAULT-DETECTION_Part_load. 2 Критерий симптома отказа для FAULT-DETECTION_Full_load С.5.11 Работа с критериями устранения отказов в случае нескольких стратегий С.5.11.1 Введение Для симптомов, которые имеют несколько стратегий, должна быть предоставлена вся информация об этих стратегиях. Однако при описании критериев обнаружения исправного состояния может иметь место ситуация, когда помимо критериев обнаружения исправного состояния существуют дополнительные критерии, которые применяются ко всем дальнейшим стратегиям. В этом особом случае критерии не должны перечисляться по отдельности, но могут быть представлены с использованием стандартного текста «АП other fault detection criteria of this symptom are not fulfilled» («Все остальные критерии обнаружения отказа по этому симптому не выполнены»). С.5.11.2 Примеры симптомов с несколькими стратегиями В таблице С.53 приведен положительный пример симптомов с несколькими стратегиями. Таблица С.53 — Положительный пример симптомов с несколькими стратегиями Ссылка Тип Псевдокод Стратегия А Стратегия мониторинга Strategy А Критерий обнаружения отказа measurement_value_1 > detection_threshold_value_1 Критерий обнаружения исправного состояния 1 1 measurement_value_1 <= detection_threshold_value_1 AND All other fault detection criteria of this symptom are not fulfilled (Все остальные критерии обнаружения отказа данного симптома не выполняются) Подтверждение отказа Стратегия Б Стратегия мониторинга Strategy В Критерий обнаружения отказа measurement_value_2 > detection_threshold_value_2 Критерий обнаружения исправного состояния 1 1 measurement_value_2 <= detection_threshold_value_2 AND All other fault detection criteria of this symptom are not fulfilled (Все остальные критерии обнаружения отказа данного симптома не выполняются) Подтверждение отказа Стратегия В Стратегия мониторинга Strategy С Критерий обнаружения отказа measurement_value_3 > detection_threshold_value_3 Критерий обнаружения исправного состояния 1 1 measurement_value_3 <= detection_threshold_value_3 AND All other fault detection criteria of this symptom are not fulfilled (Все остальные критерии обнаружения отказа данного симптома не выполняются) Подтверждение отказа Ссылка 1 Если устранение отказов для конкретной стратегии требует выполнения не только критериев обнаружения исправного состояния, но и критериев обнаружения отказов всех других стратегий, индикация последней должна быть опущена. Вместо этого должен использоваться следующий стандартный текст: «АП other fault detection criteria of this symptom are not fulfilled» (Все остальные критерии обнаружения отказа данного симптома не выполняются) В таблице С.54 приведен отрицательный пример симптомов с несколькими стратегиями. Таблица С.54 — Отрицательный пример симптомов с несколькими стратегиями STOP Ссылка Тип Псевдокод Стратегия А Стратегия мониторинга Strategy А Критерий обнаружения отказа measurement_value_1 > detection_threshold_value_1 Критерий обнаружения исправного состояния 1 1 1 1 1 measurement_value_1 <= detection_threshold_value_1 AND measurement_value_2 <= detection_threshold_value_2 AND measurement_value_3 <= detection_threshold_value_3 Подтверждение отказа Стратегия Б Стратегия мониторинга Strategy В Критерий обнаружения отказа measurement_value_2 > detection_threshold_value_2 Критерий обнаружения исправного состояния 1 1 1 1 1 measurement_value_1 <= detection_threshold_value_1 AND measurement_value_2 <= detection_threshold_value_2 AND measurement_value_3 <= detection_threshold_value_3 Подтверждение отказа Стратегия В Стратегия мониторинга Strategy C Критерий обнаружения отказа measurement_value_3 > detection_threshold_value_3 Критерий обнаружения исправного состояния 1 1 1 1 1 measurement_value_1 <= detection_threshold_value_1 AND measurement_value_2 <= detection_threshold_value_2 AND measurement_value_3 <= detection_threshold_value_3 Подтверждение отказа Разрешающие условия Ссылка 1 Все условия, необходимые для устранения отказов, подробно представлены для каждой стратегии С.5.12 Последовательность описания для нескольких записей в отношении нескольких выпусков С.5.12.1 Введение Симптом, который является идентичным для нескольких выпусков, должен быть описан одинаково, т. е. все множественные записи должны быть перечислены в одинаковом порядке для всех выпусков (см. таблицу С.55). В таблице С.55 приведен положительный пример размещения информации для последовательных выпусков. Таблица С.55 — Положительный пример размещения информации для последовательных выпусков Ссылка Тип Псевдокод Законодательство 1 1 Legal reference MCL Strategy 13 CCR 1968.2; paragraph (e) (15.2.1 )(A) 13 CCR 1968.2; paragraph (e) (15.2.2)(A) Input Out of Range High Output Functional Ссылка 1 Порядок всегда должен быть одинаковым, и каждый выпуск должен иметь постоянно возрастающий буквенно-цифровой номер В таблице С.56 приведен отрицательный пример размещения информации для последовательных выпусков. Таблица С.56 — Отрицательный пример размещения информации для последовательных выпусков Ссылка Тип Псевдокод Законодательство 1 1 Legal reference MCL Strategy 13 CCR 1968.2; paragraph (e) (15.2.1 )(A) 13 CCR 1968.2; paragraph (e) (15.2.2)(A) Output Functional Input Out of Range High Ссылка 1 Данный порядок неверен, поскольку пункт (15.2.2) предшествует пункту (15.2.1) С.5.13 Порядок описания для функциональных записей С.5.13.1 Введение Могут быть задокументированы несколько функций/версий. Цель заключается в том, чтобы иметь возможность документировать все соответствующие функции/версии для одного симптома отказа, включая другие функции подачи, которые влияют на работу мониторов. Вначале должна быть указана функция/версия, которая описывает критерии отказа симптома отказа. Она называется основной функцией. Все остальные функции, называемые функциями подачи, должны быть перечислены позже. С.5.13.2 Примеры расположения основной функции и функций подачи В таблице С.57 приведен положительный пример расположения основной функции и функций подачи. Таблица С.57 — Положительный пример расположения основной функции и функций подачи Ссылка Тип Псевдокод Функция ЭБУ 1 Main function Feeder function Feeder function Ссылка 1 Основная функция всегда должна указываться первой, а функции подачи — последующими В таблице С.58 приведен отрицательный пример расположения основной функции и функций подачи. Таблица С.58 — Отрицательный пример расположения основной функции и функций подачи Ссылка Тип Псевдокод Функция ЭБУ 1 Feeder function Main function Feeder function Ссылка 1 Функция подачи упомянута первой, но она не должна упоминаться перед основной функцией С.5.14 XOR-информация С.5.14.1 Введение При разрешении или обнаружении отказа может возникнуть ситуация, когда указанные условия могут быть правильно представлены только с использованием конструкции XOR. Предложение: Для четкого и понятного представления XOR-информации должны быть подробно описаны возможности ввода, которые необходимо выполнить. С.5.14.2 Примеры В таблице С.59 приведен положительный пример представления двух частей XOR-информации. Таблица С.59 — Положительный пример представления двух частей XOR-информации Ссылка Тип Псевдокод Разрешающие условия 1 1 IF ( "getbit(Bitmask,Bitposition) xor Bit" (getbit(Bitmask,Bitposition) == true and Bit == false) OR (getbit(Bitmask,Bitposition) == false and Bit == true) THEN ... ELSE ...) Ссылка 1 Если есть два условия, XOR-информация разрешается Приложение D (справочное) D.1 Основные данные об ингибировании Процесс должен быть построен таким образом, чтобы все условия ингибирования были известны поставщику и суммировались у него в генераторе 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 и словом «Калибровка». Однако эта ссылка представляет собой только первый раздел полной цепочки ингибирования. Компонент ПО, обозначенный как 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. D.3 Объяснение термина «жестко закодирован» Данный термин применяют к постоянным ссылкам в программном коде, которые не могут быть изменены приложением. В настоящее время они становятся известными ИТС только после изучения документации ПО. Простое машиночитаемое представление данного контекста является важным требованием для содержимого контейнера FXD. Индивидуальные механизмы ингибирования и подлежащие определению элементы описания показаны на рисунке D.2. 1 — рассматриваемая Diagnosis_function_B; 2 — калибровка; 3 — вычисление отказа; 4 — мастер проверки диагноза; 5—валидация отказа; 6—«жестко закодированный», немашиночитаемый участок цепи ингибирования; 7 — замещающее действие из документации на ПО Рисунок 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). Библиография [1] SAE J1930-DA Цифровое приложение диагностических терминов, определений, аббревиатур и сокращений систем Е/Е (Digital Annex of Е/Е Systems Diagnostic Terms, Definitions, Abbreviations, and Acronyms) [2] SAE J1979-DA Цифровое приложение режимов диагностики Е/Е (Digital Annex of Е/Е Diagnostic Test Modes) [3] SAE J2012-DA Цифровое приложение Е/Е. Диагностические определения кодов неисправностей и определения байтов типа сбоя (Digital Annex of Е/Е Diagnostic Trouble Code Definitions and Failure Type Byte Definitions) [4] ISO 22901-1:2008 Транспорт дорожный. Открытый обмен диагностическими данными. Часть 1. Требования к модели данных (Road vehicles — Open diagnostic data exchange (ODX) — Part 1: Data model specification) [5] ISO/IEC 11578:1996 Информационные технологии. Взаимодействие открытых систем. Вызов удаленных процедур (Information technology — Open Systems Interconnection — Remote Procedure Call (RPC)) [6] htto://www.electroDedia.orq/ [7] httD://www.iso.orq/obp [8] ISO 15031-5:2015 Транспорт дорожный. Связь между автомобилями и наружным оборудованием для диагностики выбросов автомобиля в окружающий воздух. Часть 5. Службы диагностики выбросов (Road vehicles — Communication between vehicle and external equipment for emissions-related diagnostics — Part 5: Emissions-related diagnostic services) [9] Окончательное постановление о регулировании. Программа регистрации региональных Правил создания переносного оборудования (Final Regulation Order. Regulation to Establish a Statewide Portable Equipment Registration Program) УДК 656.13:006.354 ОКС 35.240.60 Ключевые слова: диагностические данные, обмен данными, отказ, обнаружение, диагностика Редактор Н.А. Кузьмина Технический редактор В.Н. Прусакова Корректор И.А. Королева Компьютерная верстка И.Ю. Литовкиной Сдано в набор 09.12.2021. Подписано в печать 11.01.2022. Формат 60*84%. Гарнитура Ариал. Усл. печ. л. 23,72. Уч-изд. л. 21,50. Подготовлено на основе электронной версии, предоставленной разработчиком стандарта Создано в единичном исполнении в ФГБУ «РСТ» , 117418 Москва, Нахимовский пр-т, д. 31, к. 2. 1 ) Autosar (англ. AUTomotive Open System ARchitecture) — автомобильная архитектура открытых систем. 2 ) Атрибут nillable указывает на возможность присвоения элементу явного значения NULL.4.5 Базовая концепция FXD
4.5.1 Основные требования4.5.2 Формальное описание алгоритмов диагностики
4.5.3 Механизм наследования значений для поддержки вариантов использования
4.5.4 Реализация наследования значений
4.6 Рабочий процесс FXD
4.7 Пример рабочего процесса FXD
4.7.1 Шаг 1: Управление необработанными данными на стороне поставщика программного обеспечения электронного блока управления
4.7.2 Шаг 2: Создание файла FXD-XML
4.7.3 Шаг 3: Интеграция и уточнение информации FXD на стороне ИТС
4.7.4 Шаг 4: Генерация сводной таблицы БД
4.8 Ограничения для обновлений схемы
5 Варианты использования FXD
5.1 Основные положения
5.2 Вариант использования 1: Доставка «необработанных данных» поставщиками программного обеспечения электронного блока управления
5.3 Вариант использования 2: Генерация документации на основе необработанных данных FXD
5.3.1 Вариант использования 2.1: Создание сводной таблицы БД для официального одобрения типа ТС.
5.3.2 Вариант использования 2.2: ИРТО, основанная на FXD
6 Общие свойства элементов FXD
6.1 Атрибуты
6.1.1 Атрибут DESC_EXTENT (содержание)
6.1.2 Атрибут HREF (содержание)
6.1.3 Атрибут ID (инфраструктура)
6.1.4 Атрибут ID-REF (инфраструктура)
6.1.5 Атрибут OID (содержание)
6.1.6 Атрибут OPERATOR (содержание)
6.1.7 Атрибут SI (содержание)
6.1.8 Атрибут DESC-STATE (содержание)
6.1.9 Атрибут TI (инфраструктура)
6.1.10 Атрибут VERSION (содержание)
6.1.11 Атрибут xmkbase (инфраструктура)
6.1.12 Атрибут xmklang (инфраструктура)
6.1.13 Атрибут xsi:nil (содержание)
6.1.14 Атрибут xsktype (инфраструктура)
6.2 Вариантное кодирование
6.3 Реестры общего выбора
6.4 Ссылки на внешние документы
6.5 Ссылки на переменные ЭБУ и калибровочные метки
6.6 Общие элементы FXD, используемые для идентификации и описания
7 Описание элементов FXD
7.1 Основные положения
7.2 Элемент ADMIN-DATA
7.2.1 Основные положения7.2.2 Элемент COMPANY-DATA-REF
7.2.3 Элемент ECU-FAMILY
7.2.4 Элемент PROJECT
7.2.5 Элемент RESOURCES
7.2.6 Элемент DOC-REVISIONS
7.3 Элемент COMPANY-DATAS
7.3.1 Основные положения7.3.2 Элемент COMPANY-DATA
7.4 Элемент DATA-DICTIONARY
7.4.1 Элемент DATA-DECLARATIONS7.4.2 Элемент COMPUTATIONS
7.4.3 Элемент UNIT-SPEC
7.5 Элемент VARIABLE-DESCRIPTIONS
7.5.1 Основные положения7.5.2 ID элемента
7.5.3 Элемент COMPANY-DATA-REF
7.5.4 Элемент ECU-FUNCS
7.5.5 Элемент CONFIGURATION
7.5.6 Элемент DATA-DECLARATION, описываемый элементом VARIABLE-DESCRIPTION
7.5.7 Элемент SIMPLE-VARIABLE
7.5.8 Элемент BIT-FIELD-VARIABLE
7.5.9 Элемент STATE-GRAPH
7.6 Элемент FAULT-SYMPTOMS
7.6.1 Основные положения7.6.2 ID элемента
7.6.3 Элемент COMPANY-DATA-REF
7.6.4 Элемент ECU-FUNCS
7.6.5 Элемент CONFIGURATION
7.6.6 Элемент FAULT-IDENTIFICATION
7.6.7 Элемент MON-COMPONENT или система
7.6.8 Элемент FAULT-CLASSIFICATION
7.6.9 Элемент RATIO-GROUPS для применения в коэффициенте использования монитора (IUMPR)
7.6.10 Элемент READINESS-GROUP
7.6.11 Элемент FAULT-DETECTIONS
Определение частоты мониторинга
Один раз за срок службы ЭБУ (Once per ECU lifetime)
Непрерывный мониторинг (Continuous)
Множественный мониторинг (Multiple)
7.6.12 Элемент CENTRAL-CALIBRATION-INFOS
7.6.13 Информация элемента INHIBITIONS
7.6.14 Элемент SUBSTITUTION-FUNCTION
7.6.15 Элемент PROTECTIVE-FUNCTION
7.6.16 Элемент SIMULATION-METHOD
7.6.17 Элемент ##other-lnformation (для симптомов)
7.7 Элемент FAULT-SYMPTOM-3RD-PARTYS
7.9 Элемент FIDS
7.9.1 Основные положения7.9.2 ID элемента
7.9.3 Элемент FID-TYPE
7.9.4 Элемент ECU-FUNC
7.9.5 Элемент FAULT-SYMPTOM-REFS
7.9.6 Элемент AUXILIARY-OBJECT-REFS
7.9.7 Элемент EXPLANATION
7.10 Элемент AUXILIARY-OBJECTS
7.11 Элемент MASKS
7.12 Элемент TEXT-MAPPINGS
7.13 Любая иная информация (для контейнера)
Цифровое приложение FXD XML-схемы
Цифровое приложение словаря выбора FXD
Цифровое приложение набора правил FXD
Ингибирование симптомов отказа
Другие госты в подкатегории