Система управления бд это: Что такое СУБД? Наиболее популярные СУБД

Реляционные системы управления базами данных

Реляционные СУБД для работы с данными используют реляционную модель. Эта модель хранит любую информацию в таблицах в виде связанных записей с атрибутами.

Этот тип СУБД требует наличия структур-таблиц. Столбцы (атрибуты) такой таблицы содержат различные типы данных. Каждая запись БД воспринимается как строка в таблице, атрибуты которой представлены в виде столбцов.

Отношения и типы данных

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

Добавляя запись в таблицу, нужно распределить все её компоненты (атрибуты) по типам данных. Разные реляционные СУБД используют разные типы данных, и они не всегда взаимозаменяемы.

Подобные ограничения (как, например, с типами данных) типичны для реляционных СУБД, ведь, по сути, отношения между данными и строятся на основе ограничений.

Примечание: Базы данных NoSQL не имеют таких строгих ограничений, поскольку они не выстраивают таких отношений между данными. Чтобы узнать больше о NoSQL, читайте эту статью.

 Популярные реляционные базы данных

В данной статье мы рассмотрим три наиболее важные и популярные СУБД с открытым исходным кодом.

• SQLite: встроенная мощная система управления базами данных.
• MySQL: самая популярная и широко распространённая БД.
• PostgreSQL: продвинутая SQL-совместимая объектная СУБД с открытым исходным кодом.

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

SQLite

SQLite – это производительная библиотека, которую можно встраивать в приложения. Полноценная БД на основе файлов SQLite предлагает широкий набор инструментов для обработки всех видов данных и накладывает намного меньше ограничений, чем другие реляционные базы данных.

Приложения, использующие SQLite, не взаимодействуют с помощью интерфейса (портов, сокетов), а отправляют прямые запросы в файл, в котором хранятся данные (например БД SQLite). Благодаря этому приложение SQLite очень быстрое и производительное.

Типы данных SQLite

• NULL: пустое значение.
• INTEGER: целочисленное значение (зависимо от объёма значение хранится в 1, 2, 3, 4, 6 или 8 байтах).
• REAL: число с плавающей точкой, хранится в виде 8-байтного IEEE.
• TEXT: текстовая строка, хранится в зашифрованном виде (UTF-8, UTF-16BE или UTF-16LE).
• BLOB: бинарные данные, хранятся в том виде, в котором были введены.

Примечание: Больше о типах данных SQLite можно узнать в официальной документации.

Преимущества SQLite

• Простое строение на основе файлов: вся база данных состоит всего из одного файла, что увеличивает её портативность.
• Стандарты: несмотря на простоту, система SQLite основана на SQL. Некоторые функции опущены (RIGHT OUTER JOIN или FOR EACH STATEMENT), однако вместо них добавлены другие.
• SQLite отлично подходит для разработки или тестирования. На этих этапах почти всегда необходимо простое, но масштабируемое решение.

Недостатки SQLite

• Нет управления пользователями. Более сложные СУБД поддерживают управление пользователями (их взаимосвязями, привилегиями и т.п.). Простая СУБД SQLite такой функции не предоставляет.
• Невозможно повысить производительность. Библиотека SQLite проста в настройке и в использовании. Однако она разработана таким образом, что не позволяет путём тонкой настройки получить дополнительную производительность. То есть сделать SQLite более производительной технически невозможно.

Когда лучше использовать SQLite

• Простые встроенные приложения, которым нужна портативность, например, однопользовательские локальные приложения, мобильные приложения, игры.
• Замена диска. Обычно приложения, которым необходимо читать или записывать файлы на диск, могут использовать SQLite для получения дополнительных функций.
• Тестирование.

Когда лучше не использовать SQLite

• Многопользовательские приложения. Если приложение построено таким образом, что большое количество клиентов одновременно использует одну БД, то в такое приложение лучше внедрить полнофункциональную реляционную СУБД (например, MySQL).
• Приложения, записывающие большое количество данных. операция записи является одним из ограничений SQLite. Эта СУБД позволяет выполнять только одну операцию записи за один момент времени, следовательно, она ограничивает пропускную способность.

MySQL

MySQL – самая популярная СУБД. Это многофункциональное открытое приложение, поддерживающее работу огромного количества сайтов. Система MySQL довольно проста в работе и может хранить большие массивы данных.

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

MySQL не реализует полный стандарт SQL. Несмотря на это, MySQL предлагает множество функциональных возможностей для пользователей: автономный сервер баз данных, взаимодействие с приложениями и сайтами и т.п.

Типы данных MySQL

• TINYINT: целое число в диапазоне от -128 до 127 (1 байт).
• SMALLINT: целое число от -32768 до 32767 (2 байта).
• MEDIUMINT: число от -8388608 до 8388608 (3 байта).
• INT или INTEGER: число в диапазоне от -2147683648 до 2147683648 (4 байта).
• BIGINT: число от -2⁶³ до 2⁶³-1 (8 байт).
• FLOAT: число с плавающей точкой (4 байта).
• DOUBLE, DOUBLE PRECISION, REAL: число с двойной точностью и плавающей точкой.
• DECIMAL, NUMERIC: величины повышенной точности.
• DATE: дата.
• DATETIME: дата и время.
• TIMESTAMP: временная метка.
• TIME: время в формате hh:mm:ss.
• YEAR: год (по умолчанию хранится в виде 4 цифр, но можно настроить и 2).
• CHAR: строка фиксированной длины.
• VARCHAR: строки переменных.
• TINYBLOB, TINYTEXT: Тип TEXT позволяет хранить текст, а BLOB – изображения, звук, электронные документы и т.п. Максимальная длина – 225 символов.
• BLOB, TEXT: большие объемы текста, максимум 65535 символов.
• MEDIUMBLOB, MEDIUMTEXT: аналогично предыдущему, но максимум до 16777215 символов.
• LONGBLOB, LONGTEXT: аналогично предыдущему, но максимум до 4294967295 символов.
• ENUM: принимает только одно из значений заданного множества.
• SET: принимает любой или все элементы из значений заданного множества.

Преимущества MySQL

• Простота в работе: MySQL очень просто установить и настроить. Сторонние инструменты, в том числе визуализаторы (интерфейсы) значительно упрощают работу с данными.
• Функциональность: MySQL поддерживает огромное количество функций SQL.
• Безопасность: MySQL предоставляет много встроенных продвинутых функций для защиты данных.
• Масштабируемость и производительность: MySQL может работать с большими объёмами данных.

Недостатки MySQL

• Ограничения: структура MySQL накладывает некоторые ограничения, из-за которых не смогут работать продвинутые приложения.
• Уязвимости: метод обработки данных, применяемый в MySQL, делает эту СУБД немного менее надёжной по сравнению с другими СУБД.
• Медленное развитие: хотя MySQL является продуктом с открытым исходным кодом, он очень медленно развивается. Однако тут следует заметить, что на MySQL основано несколько полноценных баз данных (например, MariaDB).

Когда использовать MySQL

• Распределенные операции: автономный сервер баз данных MySQL поддерживает множество операций и предоставляет несколько дополнительных функций.
• Высокая безопасность данных: MySQL предлагает высокую защиту данных.
• Веб-сайты и веб-приложения: несмотря на ограничения MySQL может поддерживать работу почти любого сайта и веб-приложения. Этот гибкий и масштабируемый инструмент прост в использовании.
• Пользовательские решения: MySQL можно подогнать под строгие требования сайта или приложения.

Когда лучше не использовать MySQL

• Конфликты с SQL: поскольку MySQL всё же полностью не реализует стандартов SQL, он не полностью совместим с SQL. Потому MySQL не всегда можно интегрировать с другой СУБД.
• Слабая поддержка параллелизма: несмотря на то, что MySQL хорошо выполняет операции чтения, одновременные операции чтения и записи могут вызвать проблемы.
• Отсутствие некоторых функций (например, полнотекстового поиска).

PostgreSQL

PostgreSQL – это продвинутая открытая объектно-ориентированная СУБД. PostgreSQL реализует SQL-стандарты ANSI/ISO.

В отличие от других СУБД, PostgreSQL поддерживает очень важные объектно-ориентированные и реляционные функции баз данных: надежные транзакции ACID (атомарность, согласованность, изолированность, долговечность) и т.п.

Основанная на надёжной технологии СУБД PostgreSQL может одновременно обрабатывать большое количество задач. Поддержка согласованности достигается без блокирования операций чтения благодаря MVCC.

Хотя СУБД PostgreSQL не так популярна, как MySQL, для неё тоже разработано большое количество дополнительных инструментов и библиотек, которые упрощают работу с данными и увеличивают производительность СУБД.

Типы данных PostgreSQL

• bigint: знаковое восьмибайтное целое число.
• bigserial: восьмибайтное целое число с автоинкрементом.
• bit [(n)]: битовая строка фиксированной длины.
• bit varying [(n)]: битовая строка с переменной длиной.
• boolean: логическое значение (true/false).
• box: четырёхугольник на плоскости.
• bytea: бинарные данные.
• character varying [(n)]: строка символов с переменной длиной.
• character [(n)]: строка символов с фиксированной длиной
• cidr: адрес сети IPv4 или IPv6.
• circle: круг на плоскости.
• date: дата (год, месяц, день).
• double precision: число с плавающей точкой двойной точности (8 байт).
• inet: адрес хоста IPv4 или IPv6.
• integer: знаковое четырёхбайтовое целое число.
• interval [fields] [(p)]: промежуток времени.
• line: бесконечная линия на плоскости.
• lseg: сегмент линии на плоскости.
• macaddr: MAC (Media Access Control) адрес.
• money: валюта.
• numeric [(p, s)]: точное числовое значение с выбранной точностью.
• path: геометрический путь на плоскости.
• point: геометрическая точка на плоскости.
• polygon: закрытый геометрический путь на плоскости (полигон)
• real: число с плавающей точкой одинарной точности (4 байта).
• smallint: знаковое двухбайтное целое число.
• serial: четырёхбайтное целое число с автоинкрементом.
• text: строка символов с переменной длиной.
• time [(p)] [without time zone]: время дня (без часового пояса).
• time [(p)] with time zone: время дня и часовой пояс.
• timestamp [(p)] [without time zone]: временная метка (дата и время) без часового пояса.
• timestamp [(p)] with time zone: временная метка с часовым поясом.
• tsquery: запрос текстового поиска.
• tsvector: документ текстового поиска.
• txid_snapshot: снапшот ID-транзакции уровня пользователя.
• uuid: универсальный уникальный идентификатор.
• xml: данные XML.

Преимущества PostgreSQL

• Система управления базами данных PostgreSQL открытая, SQL-совместимая, свободная.
• Активное сообщество PostgreSQL поможет найти решение любой проблемы, связанной с СУБД, в любое время суток.
• Поддержка сторонних инструментов: помимо встроенных продвинутых функций, PostgreSQL поддерживает множество открытых сторонних инструментов для проектирования, управления данными и т.п.
• Масштабируемость и расширяемость.
• Объектно-ориентированность.

Недостатки PostgreSQL

• Производительность: в некоторых ситуациях производительность PostgreSQL ниже, чем у MySQL.
• Невысокая популярность.
• В связи с вышеперечисленными недостатками не все хостинг-провайдеры поддерживают PostgreSQL.

Когда использовать PostgreSQL

• Если приложению необходима целостность данных.
• Для выполнения сложных пользовательских задач.
• Если в будущем приложению понадобится более надёжная платная БД, с PostgreSQL легче будет перейти.
• Для поддержки приложений со сложной структурой PostgreSQL предлагает специальный набор функций.

Когда лучше не использовать PostgreSQL

• Если приложению нужны быстрые операции чтения.
• Если приложению не нужна абсолютная целостность данных, ACID или сложная структура, PostgreSQL может стать слишком сложным решением.
• Репликация данных сложнее, чем в MySQL, потому в кластерах PostgreSQL лучше не использовать.

Система управления базой данных (субд)

Термин и определение

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

Научные статьи на тему «Система управления базой данных (СУБД)»

При работе с данными используют специальные системы, которые называются системами управления базами данных…
Определение 2 Система управления базами данных (СУБД) является совокупностью программных и лингвистических…
баз данных К основным функциям СУБД относятся определение данных (описание структуры БД), их обработка…
И еще одна функция СУБД — это управление данными, под которым, как правило, понимается защита данных…
Состав СУБД Современная СУБД состоит из следующих компонентов: Ядра, отвечающего за управление данными

Статья от экспертов

В статье представлены основные признаки современных NoSQL решений, описаны некоторые типы NoSQL СУБД, осуществлен сравнительный анализ реляционного подхода и подхода, основанного на NoSQL.

Научный журнал

Creative Commons

Требования к современным базам данных СУБД (системы управления базами данных) — программные средства…
Данные могут храниться как в файловых системах, так и в оперативной памяти (кэширование), как на локальном…
Классификации СУБД СУБД можно классифицировать по модели данных: иерархические; реляционные; объектно-ориентированные…
Автор24 — интернет-биржа студенческих работ Инструменты управления СУБД Для внесения изменений в базу…
Реляционные базы данных и NoSQL Доминирующей в проектировании СУБД является концепция реляционных баз

Статья от экспертов

В работе рассмотрено понятие систем управления базами данных, виды систем управления базами данных, основные элементы баз данных, возможные сферы их применения.

Научный журнал

Creative Commons

Повышай знания с онлайн-тренажером от Автор24!

• 📝 Напиши термин
• ✍️ Выбери определение из предложенных или загрузи свое
• 🤝 Тренажер от Автор24 поможет тебе выучить термины, с помощью удобных и приятных карточек

Введение в бортовую диагностику (OBD)

1 Комментарий / Двигатель, Управление двигателем, Особенности двигателя, Избранные статьи, Технология, Особенности технологии / Автор Ромен Николя

OBD определение

«Бортовая диагностика» представляет собой комплексную электронную систему, которая обнаруживает неисправности, связанные с выбросами выхлопных газов, в легковых автомобилях, малотоннажных грузовиках, а с некоторых лет также и в большегрузных транспортных средствах, которые работают на двигателях внутреннего сгорания. Эти типы двигателей производят токсичные выхлопные газы, такие как HC, CO, NOx и сажа. Количество этих выбросов регулируется законом во многих странах (см. карту регулирования выбросов). Чтобы выполнить эти законодательные требования, OEM-производители устанавливают комплексные системы контроля и очистки выхлопных газов. Эти системы и связанные с ними компоненты должны контролироваться так называемой системой бортовой диагностики.

Законы OBD требуют, чтобы все компоненты и подсистемы, влияющие на выбросы и подключенные к блоку управления двигателем (ECU), нуждались в контроле и диагностике. Компоненты можно разделить на:

• Датчики: датчик O2, датчики температуры, датчики давления и т. д.
• Приводы: топливные форсунки, катушки зажигания, дроссельные заслонки, фазовращатели, клапан рециркуляции отработавших газов и т. д.

Со стороны системы необходимо контролировать несколько подсистем, например, неисправность всей подсистемы, которая приводит к определенному увеличению выбросов. Таких подсистем:

• Система впрыска топлива
• Система зажигания
• Система очистки выхлопных газов
• Система продувки адсорбера

На следующем рисунке показана полная система управления двигателем со всеми соответствующими компонентами, подключенными к центральному ЭБУ.

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

Например, неисправность датчика скорости автомобиля не влияет или оказывает незначительное влияние на выбросы. Датчик используется ECU для оптимизации нескольких функций управляемости, которые обычно не влияют на выбросы. Но этот датчик также используется ЭБУ для запуска так называемого алгоритма «обнаружения неровной дороги». И этот алгоритм используется диагностикой пропусков зажигания. Поэтому, если датчик выходит из строя, обнаружение неровной дороги не может произойти, что может помешать диагностике пропусков зажигания. В этом случае отказ датчика влияет на выбросы, поскольку диагностика пропусков зажигания используется для обнаружения пропущенных событий сгорания (которые приводят к высоким выбросам углеводородов).

Прогресс в области электроники позволяет диагностировать все или большинство датчиков и исполнительных механизмов, подключенных к блоку управления двигателем. Текущая система управления двигателем (EMS) для 4-цилиндрового бензинового двигателя включает в себя более 25 датчиков и от 30 до 35 исполнительных механизмов. Современные EMS с непосредственным впрыском имеют на 50% больше датчиков и исполнительных механизмов.

Все эти компоненты должны быть электрически продиагностированы, некоторые из них также на предмет отказов рациональности. Кроме того, системы электропривода, такие как электронное управление дроссельной заслонкой, требуют расширенных диагностических функций по соображениям безопасности, чтобы избежать, например, нежелательного ускорения. Хотя эта диагностика не является частью OBD, требуемой по закону, она подпадает под функции OBD и соответствующие алгоритмы.

Таким образом, в целом в приличном программном обеспечении EMS 40% кода связано с диагностикой. Текущая система EMS содержит около 9000–12000 калибровочных значений и таблиц, что означает, что в каждом автомобиле калибруется около 3500–4500 диагностических параметров. Эти цифры подчеркивают важность современных систем OBD.

Законодательные требования OBD

OBD II и EOBD

OBD II является обязательным требованием в США с 1997 г., тогда как EOBD является законодательным требованием в Европе с 2000 г.

Ниже приводится сводка законодательных требований США и Европы.

• Обнаружение электрических отказов компонентов, связанных с выбросами
• Обнаружение нарушений правдоподобия компонентов, связанных с выбросами
• Неисправности исполнительных механизмов
• Обнаружение деградации компонентов и подсистем, связанных с выбросами:
  • Каталитический нейтрализатор (HC, CO и NOx)
  • 02 датчика
  • Сажевые фильтры (в Европе)
  • Топливная система
  • Осечка
  • Обнаружение утечек в испарительной системе (в США)
  • Электрическая диагностика испарительной системы (в Европе)
  • Вентиляция картера (в США)
  • Потеря хладагента кондиционера
  • Система вторичного воздуха (в США)
  • Термостат охлаждающей жидкости (в США)

Критерии отказа, индикатор MIL, режимы по умолчанию

В случае отказа должны выполняться следующие действия:

Наивысший приоритет для отказов, которые могут повредить двигатель или создать угрозу безопасности водителя и поэтому требуют режима по умолчанию: Отказы типа A

Действия:

• Немедленное MIL (индикатор неисправности) при обнаружении отказа.
• Режим по умолчанию, т.е. ограничение нагрузки или скорости, положение приводов по умолчанию, …

Примерами отказов типа А являются повреждение катализатора, отказ катушек зажигания, отказ электронного управления дроссельной заслонкой…

Более низкий приоритет для отказов, вызывающих превышение уровней выбросов OBD II/EOBD: Отказы типа B .

Действия:

• Освещение MIL после или во время 2 ^и последовательных ездовых циклов, в которых обнаружена неисправность.
• Если возможно, можно ввести режим по умолчанию. Примером режима по умолчанию может быть использование модели температуры охлаждающей жидкости при отказе датчика охлаждающей жидкости.

Пределы обнаружения для OBD II

Американская OBD определяет пределы обнаружения в процентах от пределов выбросов. Таким образом, более низкие пределы выбросов приводят к более низким пределам OBD, что делает необходимым наличие надежных алгоритмов обнаружения OBD II. Он должен быть в состоянии обнаруживать все более и более мелкие отказы, обеспечивая при этом отсутствие ложного обнаружения, что может привести к недоверию к стороне, используемой для системы OBD.

Определение отказа OBD II по выбросам описано на следующей диаграмме:

Если отказ компонента или системы может привести к увеличению выбросов автомобиля выше пределов OBDII, MIL должен быть включен.

В процессе сертификации юридические органы могут потребовать, чтобы была проведена демонстрация отказа или деградации определенных компонентов. Во время этой демонстрации OEM-производитель должен подтвердить, что MIL включен, прежде чем пределы выбросов OBDII будут превышены в ходе теста на выбросы.

Пределы обнаружения для EOBD

Законодательство EOBD определяет пороги EOBD как абсолютные пределы выбросов. По сравнению с законодательными требованиями США, целью EOBD является более надежное обнаружение, поскольку пределы выбросов EOBD в целом выше, чем ограничения США. Отрицательное влияние заключается в том, что компонентам и подсистемам предоставляется более высокий допуск, прежде чем сбой должен быть обнаружен.

Тем не менее, законодательство Euro 6 OBD снижает пределы выбросов EOBD, отсюда и определение «дефектной» детали.

Определение неисправности EOBD по выбросам описано на следующей диаграмме:

Применяется тот же процесс сертификации, что и для OBD II.

Подсветка MIL и удаление неисправности

После включения MIL может быть отключена в следующих случаях:

• После 3-х ^-го -го цикла вождения без обнаружения неисправности
• После сервисной команды в гараже

Неисправность, хранящаяся в ЭБУ (Стоп-кадр), может быть удалена после:

• Отчет о 40 ездовых циклах без сбоев
• Сервисная команда в гараже

Мнение Ромена:

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

США: бортовая диагностика | Транспортная политика

История

Системы бортовой диагностики (OBD) интегрируются в компьютеры новых автомобилей для контроля за выбросами. Требования OBD первого поколения были реализованы в Калифорнии в 1988 году и требовались для всех автомобилей 1991 года и новее. Сегодня требования OBD применяются к автомобилям малой грузоподъемности и двигателям большой мощности как в Калифорнии, так и в соответствии с федеральными требованиями EPA.

Калифорнийский регламент OBD

Калифорнийские требования OBD для автомобилей малой грузоподъемности и двигателей большой мощности, используемых в транспортных средствах полной разрешенной массой до 14 000 фунтов (автомобили средней грузоподъемности), были введены в два этапа:

• OBD I — OBD I был первым постановлением OBD в Калифорнии, которое требовало от производителей контролировать некоторые компоненты контроля выбросов на транспортных средствах. Требуемые на всех автомобилях 1991 года и новее, системы OBD I были не настолько эффективны, насколько это возможно, поскольку они ограничивались контролем только нескольких компонентов, связанных с выбросами, и не были откалиброваны на определенный уровень характеристик выбросов.

• OBD II — системы OBD II были разработаны для устранения недостатков OBD I и повышения удобства использования системы для специалистов по обслуживанию. Это более строгое регулирование OBD второго поколения началось поэтапно в 1994. С 1996 года его внедрение требуется для всех новых легковых и грузовых автомобилей, работающих на бензине и альтернативном топливе, продаваемых в Калифорнии. Все легковые и грузовые автомобили с дизельным двигателем 1997 года выпуска и новее также должны соответствовать требованиям OBD II.

Калифорнийские требования OBD для двигателей большой мощности для транспортных средств с полной массой более 14 000 фунтов также были введены в два этапа, а именно: диагностическая система, называемая системой диагностики производителя двигателя (EMD).

HD OBD — начиная с 2010 года требования OBD для двигателей большой мощности будут постепенно вводиться в действие. К 2013 году системы EMD будут сняты с производства, и для всех двигателей большой мощности, предлагаемых для продажи в Калифорнии, также потребуются системы OBD. В последний раз в правило HD OBD вносились поправки 31 июля 2013 г., и оно включает поправки, которые ускоряют дату начала внедрения системы OBD на двигателях с альтернативным топливом с 2020 модельного года до 2018 модельного года и смягчают некоторые требования к системам OBD на гибридных автомобилях большой грузоподъемности. автомобилей 2013-2015 годов выпуска. См. обновленный информационный дайджест для сводки изменений.

Федеральные правила OBD

После введения требований OBD в Калифорнии, правила OBD также были приняты Агентством по охране окружающей среды США. Следующие шаги были наиболее важными шагами в разработке федеральных требований к OBD:

• Начиная с 1994 модельного года, EPA требует наличия систем OBD на легковых автомобилях (LDV) и малотоннажных грузовиках (LDT).
• С 2005 года системы OBD стали обязательными для большегрузных транспортных средств и двигателей полной массой до 14 000 фунтов.
• В декабре 2008 года Агентство по охране окружающей среды (EPA) завершило разработку правил БД для двигателей большой грузоподъемности 2010 года и более поздних версий, используемых в шоссейных транспортных средствах полной разрешенной массой более 14 000 фунтов, и внесло изменения в требования бортовой системы диагностики для тяжелых условий эксплуатации с полной разрешенной массой до 14 000 фунтов, чтобы привести их в соответствие с требованиями для двигателей более Полная масса 14 000 фунтов.

Технические стандарты

Калифорнийские правила для легких и тяжелых грузов определяют ряд общих требований к световым индикаторам неисправности (MIL), кодам неисправностей, мониторингу, пороговым значениям и стандартизированным коммуникациям, общим для всех систем OBD. Эти требования, изложенные в следующих разделах, также применяются к системам, предназначенным для соответствия федеральным требованиям США.

Возможности бортовой диагностики с системами OBD II встроены в аппаратное и программное обеспечение бортового компьютера автомобиля для контроля каждого компонента, который может повлиять на характеристики выбросов. Каждый компонент проверяется диагностической процедурой, чтобы убедиться, что он работает правильно. При обнаружении проблемы или неисправности система OBD II включает сигнальную лампочку на приборной панели автомобиля, чтобы предупредить водителя. Этот предупреждающий индикатор обычно отображает фразу «Проверьте двигатель» или «Скоро обслужит двигатель». Система также сохранит важную информацию об обнаруженной неисправности, чтобы специалист по ремонту мог точно найти и устранить проблему.

MIL и требования к коду неисправности

Индикатор неисправности (MIL) расположен на стороне водителя на приборной панели. За исключением проверки работоспособности, когда он загорается на 15-20 секунд при включенном зажигании перед запуском двигателя, обычно он загорается только тогда, когда система бортовой диагностики обнаружила и подтвердила неисправность, которая может увеличить выбросы.

Прежде чем загорится MIL, необходимо выполнить ряд действий. Когда OBD определяет, что возникла неисправность, он генерирует и сохраняет «ожидающий код неисправности» и «стоп-кадр» данных двигателя. В этот момент MIL не загорается. Если неисправность обнаруживается снова до следующего ездового цикла, в котором отслеживается подозрительная система или компонент, MIL горит постоянно, и генерируется и сохраняется код неисправности «MIL-on» или «подтвержденный», а также «стоп-кадр». данных двигателя. Если неисправность не обнаружена к концу ездового цикла, «ожидающий код неисправности» стирается.

За исключением пропусков зажигания и неисправностей топливной системы, если неисправность не будет обнаружена в течение следующих трех ездовых циклов, контрольная лампа MIL может быть погашена, но код неисправности все еще сохраняется в течение как минимум 40 циклов прогрева двигателя. MIL также можно погасить, а коды неисправностей стереть с помощью сканирующего прибора, который технические специалисты используют для диагностики неисправностей. Альтернативные стратегии освещения MIL также возможны, но требуют одобрения.

Мониторинг

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

• Обеспечьте надежное обнаружение неисправностей, избегая ложных срабатываний и ложных указаний на неисправности,
• Обеспечить мониторинг в условиях, которые можно разумно ожидать при нормальной эксплуатации и использовании транспортного средства,
• Убедитесь, что во время цикла FTP будет выполняться мониторинг.

Для количественной оценки частоты мониторинга коэффициент производительности монитора при использовании определяется как:

Коэффициент эффективности мониторинга при использовании = количество событий мониторинга / количество событий вождения

Для каждого компонента и подсистемы, требующих контроля, требуется свой коэффициент. Например, для большегрузных двигателей 2013 года и позже минимально допустимое значение этого коэффициента составляет 0,100 (т.е. контроль должен происходить не реже, чем при 1 поездке автомобиля из 10).

Требования к мониторингу OBD Systems в Калифорнии

Система/компонент	Параметр, требующий мониторинга
Топливная система	Регулятор давления в топливной системе
	Количество инъекций
	Момент впрыска
	Контроль обратной связи
Осечка	Обнаружение постоянных пропусков зажигания
	Определение % пропусков зажигания на 1000 циклов двигателя (двигатели 2013 г. и позже)
EGR (рециркуляция отработавших газов)	Низкий расход
	Высокий расход
	Медленный отклик
	Работа охладителя EGR
	Характеристики катализатора EGR
	Контроль обратной связи
Давление наддува	Пониженный наддув
	Превышение наддува
	Медленный отклик
	Наддувочный воздух при охлаждении
	Контроль обратной связи
Катализатор NMHC	Эффективность преобразования
	Обеспечение обогрева DPF
	Подача исходного газа SCR (например, NO 2 )
	Обеспечить очистку NMHC после DPF
	Обеспечить очистку от аммиака
	Старение катализатора
SCR (избирательное каталитическое восстановление) Катализатор NOx	Эффективность преобразования
	Восстановитель СКВ: производительность доставки, уровень бака, качество и управление обратной связью впрыска
	Старение катализатора
Адсорбер NOx	Возможности адсорбера NOx
	Функция десорбции подачи топлива
	Контроль обратной связи
DPF (сажевый фильтр)	Эффективность фильтрации
	Частая регенерация
	Преобразование NMHC
	Неполная регенерация
	Отсутствует подложка
	Подача топлива с активной регенерацией
	Контроль обратной связи
Датчики выхлопных газов	Для датчиков состава топливовоздушной смеси и датчиков NOx: производительность, неисправность цепи, обратная связь и возможность мониторинга
	Другие датчики выхлопных газов
	Функция обогрева датчика
	Неисправность цепи нагревателя датчика
VVT (изменение фаз газораспределения)	Ошибка цели
	Медленный отклик
Система охлаждения	Термостат
	Неисправность цепи датчика ЕСТ
	Цепь датчика ЕСТ вне допустимого диапазона
	Неисправности цепи датчика ECT
CCV (клапан закрытого бачка)	Целостность системы
Комплексный мониторинг компонентов
Стратегия сокращения выбросов при холодном запуске
Мониторинг других систем контроля выбросов

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

Мониторинг также требуется для всех других систем контроля выбросов, которые не указаны конкретно. Примеры включают: ловушки углеводородов, системы управления HCCI или вихревые регулирующие клапаны.

Критерии неисправности

Критерии неисправности для различных перечисленных выше неисправностей различаются в зависимости от системы или компонента и отдельного контролируемого параметра. В некоторых случаях, таких как системы управления с обратной связью, проверки рациональности датчиков и проверки на наличие неисправностей в цепи, используется критерий «годен/не годен». В других случаях, таких как топливная система, рециркуляция отработавших газов, физические параметры турбонагнетателя и производительность системы доочистки, система БД должна быть в состоянии определить, когда износ или другие изменения приводят к превышению установленного порога выбросов.

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

При определении критериев неисправности для мониторов дизельных двигателей, которые должны указывать на неисправность до того, как выбросы превысят пороговое значение выбросов (например, в 2,0 раза больше любого из применимых стандартов), цикл испытаний на выбросы и стандарт, который приведет к более высоким выбросам при следует использовать неисправность того же уровня. Некоторая корректировка возможна для тех компонентов, которые редко регенерируются.

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

Чтобы учесть тот факт, что современные технологии могут оказаться недостаточными для обнаружения всех неисправностей при требуемом пороге, в правила была внесена некоторая гибкость. Производитель может запросить более высокий порог излучения для любого монитора, если наиболее надежный разработанный метод контроля требует более высокого порога. Кроме того, критерии неисправности фильтра твердых частиц могут быть пересмотрены, чтобы исключить обнаружение конкретных видов отказов (например, частично оплавленных подложек или небольших трещин), если наиболее надежный разработанный метод мониторинга не может обнаружить такие отказы.

Доступен ряд других исключений, включая возможность отключения мониторинга OBD при температуре окружающей среды при запуске двигателя ниже 20°F или на высоте более 8000 футов над уровнем моря.

Требования к стандартизации

К системам OBD предъявляются требования стандартизации, которые делают возможной диагностику с помощью универсального сканирующего прибора, доступного для всех, а не только для ремонтных мастерских производителя. Требования стандартизации включают:

• Стандартный разъем канала передачи данных
• Стандартный протокол для связи со сканером
• Требования к отслеживанию коэффициента производительности при использовании и отслеживанию времени работы двигателя
• Производители двигателей должны предоставить послепродажному обслуживанию и ремонту информацию об услугах, связанных с выбросами
• Стандартизированные функции, обеспечивающие доступ к информации с помощью универсального сканера. Эти функции включают в себя:
  • Состояние готовности: Система OBD указывает «завершено» или «незавершено» для каждого из контролируемых компонентов и систем.
  • Поток данных: через стандартизированный разъем канала передачи данных доступен ряд определенных сигналов. Некоторые из них включают в себя: данные, относящиеся к крутящему моменту и скорости, температуре, давлению, параметрам управления топливной системой, кодам неисправностей и связанным с ними данным, расходу воздуха, данным системы рециркуляции отработавших газов, данным турбонагнетателя и данным о доочистке.
  • Стоп-кадр: значения многих важных параметров, доступных в потоке данных, сохраняются при обнаружении неисправности.
  • Коды неисправностей
  • Результаты испытаний: результаты самого последнего мониторинга компонентов и систем, а также пределы испытаний, установленные для мониторинга соответствующих компонентов и систем, сохраняются и становятся доступными через канал передачи данных.
  • Идентификация калибровки программного обеспечения: проверочный номер калибровки программного обеспечения.
  • Идентификационный номер автомобиля (VIN)
  • Удаление диагностической информации, связанной с выбросами: диагностическая информация, связанная с выбросами, может быть удалена по команде сканирующего прибора (универсального или расширенного) или если питание бортового компьютера отключено.

Недостатки

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