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

Управление базами данных — классификация, работа (систем)

Опубликовано 07.06.2022

Содержание:

• 1 Система управления базами данных — это что
• 2 Основной функционал СУБД
• 3 На чем основано управление базами данных
• 4 Классификация СУБД
  • 4.1 Модель данных
  • 4.2 Степень распределенности
  • 4.3 Метод доступа
• 5 Нереляционные БД
• 6 Заключение

Система управления базами данных — это что

Базы данных есть у множества сайтов. Конечно, не у всех — например, сайт-визитка в этом не нуждается, т. к. не размещает информацию в постоянном режиме. Но интернет-магазин способен полноценно функционировать только при наличии баз данных. В них содержатся перечень и личные сведения клиентов, информация о заказах, прайсы, каталоги, статистика, отчетность и т. д. Любые данные легко вносятся в БД и извлекаются из нее. Внеся информацию в одну строку, администратор получает сопутствующие изменения в остальных. Это позволяет организовать более простую и быструю работу с базами данных, чем перенос сведений из одной таблицы в другую. Сегодня наибольшей популярностью продолжают пользоваться реляционные БД, работа которых регулируется языком SQL. Ранее он применялся юзерами, но постепенно совершенствовался и уже стал инструментом разработчиков. 

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

Основной функционал СУБД

К главному функционалу СУБД относят:

• управление информацией на внешних источниках (дисках) и в ОЗУ;
• ведение журналов вносимых корректировок;
• организацию резервного копирования сведений и налаживание работы БД после повреждений в результате различных неполадок;
• поддержку языков описания сведений и осуществления действий с ними.

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

На чем основано управление базами данных

Управление БД основано на ее особой структуре:

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

Классификация СУБД

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

Модель данных

Все базы данных в зависимости от структуры и особенностей обработки информации подразделяют на:

1. Иерархические — Google App Engine Datastore API, Cache. Для отображения данных используют древовидную структуру (иерархический принцип). Начальным элементом выступают объекты (каталоги и файлы с информацией) разных уровней, между которыми существуют связи. «Предки» находятся на высоких уровнях (ближе к корню), «потомки» — на низких. «Потомок» всегда обладает единственным «предком», а у «предков» объекты-потомки могут быть (причем в нескольких экземплярах, тогда они являются братьями-близнецами) или отсутствовать совсем.
2. Сетевые — Cache. Эти БД схожи с иерархическими, но «потомки» способны обладать любым числом «предков».
3. Реляционные — IBM DB2, Microsoft SQL Server и Oracle Database от одноименных разработчиков, являющихся лидерами рынка. Сведения в этих БД представлены понятно и наглядно в виде таблиц. Каждая строка с записанной информацией имеет уникальный идентификатор — ключ. Сегодня почти все разработчики создают продукты, устанавливая ориентиром реляционные СУБД. 
4. Объектно-ориентированные — GemStone. Информация представлена объектами, их классами, методами и атрибутами. Эти СУБД раздвигают границы применения языков программирования в тех ситуациях, когда нужно осуществить обработку сложноструктурированной информации, сохраняя производительность БД на достаточном уровне.
5. Объектно-реляционные — IBM DB2, Database от Oracle, MS SQL Server,  PostgreSQL. Эти СУБД применяют структуру и функционал объектно-ориентированных систем управления. Все реляционные СУБД по своей сути выступают как объектно-реляционные.

Схема реляционной базы данных

Степень распределенности

По этому параметру СУБД классифицируют как локальные и распределенные. Первые полностью размещены на одном ПК, а отдельные блоки вторых занимают пространство на различных (двух или нескольких) машинах.

Метод доступа

При помощи данного параметра СУБД разделяют на:

• Файл-серверные — FoxPro, Paradox, MS Access. Все сведения размещены на файл-сервере, а СУБД находится на клиентском ПК (рабочей станции). Юзер получает доступ к БД через локальную сеть. К плюсам относят небольшой уровень нагрузки на процессор файл-сервера, а минусов, к сожалению, значительно больше:
  • повышенная загруженность локальной сети;
  • трудности либо перебои с централизованным управлением;
  • проблемы с надежностью передачи и безопасностью данных.

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

• Клиент-серверные — IBM DB2, MySQL, ЛИНТЕР, Database от Oracle, PostgreSQL, Firebird и др. СУБД вместе со всей базой находится на сервере и обрабатывает запросы пользователей централизованно, предоставляя непосредственный доступ к сведениям. К минусам относят особые условия работы сервера. К плюсам — слабую сетевую загруженность, удобное централизованное управление, повышенный уровень доступности и безопасности.
• Встраиваемые — Firebird Embedded, SQL Server Compact от MS, BerkeleyDB и др. В этих случаях СУБД выступает фрагментом отдельного программного обеспечения и не нуждается в установке на компьютер или рабочую станцию. Система управления хранит сведения своего ПО локально и не предназначена для коллективного сетевого использования. Обычно ее реализуют в виде библиотеки, которую подключают к приложению. Последнее получает доступ к информации через SQL либо API.

Нереляционные БД

Отдельно скажем о нереляционных БД. Они хранят информацию не в строгих таблицах (как реляционные базы данных) и предоставляют к ней простой и быстрый доступ посредством API, SQL и других языков. Их широко используют в web-приложениях реального времени и для хранения объемных данных. Главные достоинства СУБД — высокий уровень доступности и масштабируемости. NoSQL БД быстро реагируют на постоянно изменяющиеся требования и полноценно работают с облаком, поэтому обладают особой популярностью среди разработчиков. Когда организации нужно как можно быстрее внедрить инновации, сохранить гибкость и возможность работы в любом масштабе, нереляционные СУБД становятся отличным помощником. 

Заключение

Мы объяснили вам, что такое СУБД, в чем заключается функционал и как их классифицируют. Если у вас есть вопросы, можете задать в специальной форме ниже или позвонить специалистам «АйТи Спектр». Мы разъясним вам сложные моменты и подскажем, как можно усовершенствовать администрирование сетей.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

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

совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.

Научные статьи на тему «Система управления базами данных»

Основные функции СУБД Создание базы данных, ее хранение, обеспечение доступа пользователей к данным. ..
осуществляются с помощью специальных программных инструментов – систем управления базами данных….
Определение 1 Система управления базами данных (СУБД) – это комплекс языковых и программных средств…
Восстановление баз данных после сбоев….
Управление доступом к данным.

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

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

Creative Commons

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

СУБД Определение 1 Система управления базами данных (СУБД) – это универсальный программный инструмент…
обслуживания и создания баз данных и пользовательских приложений для самых разных предметных областей. ..
Выделяют средства для создания: схем и таблиц баз данных, которые отображают их связи; запросов выборки…
Система доступа к данным строится на основе ядра БД Access Database Engine, которое выполняет сохранение…

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

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

Раскрываются основы технологии построения информационных систем с возможностью их простого модульного расширения без перекомпиляции исходного кода и элементами объектно-ориентированных систем управления базами данных. Технология построения основана на использовании реляционных СУБД.

Creative Commons

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

Еще термины по предмету «Автоматизация технологических процессов»

Автоматизация проектирования

создание средств и методов, позволяющих осуществлять проектирова- 5 ние с использованием средств вычислительной техники. Объектом проектирования может быть технологический процесс, конструкторская работа, энергетическая сеть, система обработки данных (СОД), автоматизированная система управления (АСУ) и др. Применение средств автоматизации проектирования предполагает взаимодействие человека и ЭВМ в процессе проектирования.

Бункерное загрузочное устройство

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

SCADA

(англ. Supervisory Control And Data Acquisition) диспетчерское управление и сбор данных, инструментальная программа для разработки программного обеспечения систем управления технологическими процессами в реальном времени и сбора данных.

• Система управления базами данных, СУБД
• Система управления базами данных (СУБД)
• Система Управления Базами Данных (СУБД)
• Система управления базой данных (СУБД)
• Система управления распределенными базами данных, СУРБД
• База данных
• Oracle7 DBMS ( Oracle7 система управления базой данных )
• Система управления банком данных
• Система баз данных (database system)
• Управление данными
• Библиографическая база данных
• Программа базы данных
• База данных ГИС
• База данных рисков
• Администратор базы данных
• Навигация в базе данных
• Структура базы данных
• Администрирование базы данных
• База данных (database)
• Ведение базы данных

Смотреть больше терминов

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

1. Напиши термин
2. Выбери определение из предложенных или загрузи свое
3. Тренажер от Автор24 поможет тебе выучить термины с помощью удобных и приятных карточек

Что такое бортовая система диагностики, OBDII?

OBDII — это интерфейс бортовой диагностики (OBD) второго поколения.

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

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

OBDII регулируется несколькими стандартами, включая ISO 11898, SAE J1962, J1850, J1939, J1978, J1979, J2012 и J2178-1. OBDII также состоит из нескольких элементов, в том числе:

• Комплексный набор датчиков, управления двигателем и выхлопом
• Общие функции автомобиля, такие как контроль усилителя руля, состояние аккумулятора, срабатывание подушки безопасности и т. д.
• Интерфейсы приборной панели для водителя
• Диагностический разъем (DLC) для использования техниками ( Рисунок 1 ).

Рисунок 1: Системы OBDII состоят из нескольких элементов, включая датчики, элементы управления, средства диагностики, а также интерфейсы для водителя и техника. (Изображение: SMLease Design)

В настоящее время интерфейс OBD II через разъем J1962 использует пять протоколов передачи сигналов, в том числе:

  1. SAE J1850 широтно-импульсная модуляция (ШИМ) (41,6 кбод, стандарт Ford Motor Company)

  2. SAE J1850 с переменной шириной импульса (VPW) (10,4/41,6 кбод, стандарт General Motors)

  3.

ISO 9141-2 (10,4 кбод, используется в автомобилях Chrysler, европейских и азиатских странах) 9 0003

  4. ISO 14230 KWP2000 (протокол ключевого слова 2000) Существует два варианта ISO14230-4:

• 5 бод инициализация, 10,4 кбод
• Быстрая инициализация, 10,4 Кбод

  5. ISO 15765 Шина CAN (250 кбит/с или 500 кбит/с) ISO15765-4 — новейший протокол. Существует четыре варианта, которые отличаются длиной идентификатора и скоростью шины.

• 11-битный идентификатор, 500 кбод
• 29-битный идентификатор, 500 кбод
• 11-битный идентификатор, 250 кбод
• 29-битный идентификатор, 250 кбод

По данным General Motors, кодирование VPW имеет более низкий уровень электромагнитных помех, чем кодирование PWM. Это связано с тем, что для кодирования VPW требуется только один переход на передаваемый бит, тогда как для PWM требуется два.

Схема кодирования VPW реализована с использованием контроллера канала передачи байтов (BDLC), который формирует битовую структуру данных и обрабатывает все коммуникации.

Как и другие реализации OBD, VPW — это протокол с одним проводом, который снижает стоимость и вес соответствующего жгута проводов. Это недорогой протокол без ведущего устройства, который включает в себя арбитраж, проверку циклическим избыточным кодом (CRC) и возможности подтверждения.

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

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

Интерфейс OBDII

OBDII использует стандартизированный порт цифровой связи для передачи данных в режиме реального времени и стандартизированной серии DTC. Спецификация OBDII требует использования 16-контактного гнезда (2 × 8) J19.62 разъема в автомобиле ( рис. 2 ):

• Контакт 1 для положительной линии шины SAE J1850 PWM и VPW
• Штырек 4 — это масса шасси
• Контакт 5 — сигнальная земля
• Контакт 6 имеет высокий уровень CAN для ISO 15765-4 и SAE J2284
• Pin 7 — это K-линия ISO 9141-2 и ISO 14230-4
.
• Контакты 8, 9, 11, 12 и 13 предназначены для индивидуальной настройки производителем.
• Контакт 10 предназначен только для отрицательной шины SAE J1850 PWM, не используется для SAE 1850 VPW
• Контакт 14 — низкий уровень CAN для ISO 15765-4 и SAE J2284
• Контакт 15 — это L-линия ISO 9141-2 и ISO 14230-4
.
• Контакт 16 для напряжения батареи

Рисунок 2: Расположение контактов 16-контактного интерфейсного разъема J1962 OBDII . (Изображение: Википедия)

В отличие от более ранних разъемов OBDI под капотом, разъем OBDII DLC должен находиться в пределах двух футов (0,61 м) от рулевого колеса в кабине автомобиля, чтобы обеспечить легкий доступ.

ОБДIII
OBDIII в настоящее время находится в разработке. Это относится к «удаленному OBD», с помощью которого будущие автомобили будут иметь возможность беспроводной отправки предупреждений DTC в удаленные места, такие как беспроводной телефон, местная ремонтная мастерская или станция проверки выбросов.

Автомобили с OBDIII будут более способны исправить любое состояние, вызывающее предупреждение DTC. Цель состоит в том, чтобы владелец такого транспортного средства не должен был отвозить его на станцию ​​для проверки выбросов, если только он не указывает на активные неисправности, связанные с выбросами.

С текущим OBDII у владельца транспортного средства нет времени, чтобы исправить проблему, если есть предупреждение DTC. Однако с OBDIII у владельца будет определенный срок для устранения кодов неисправности. Меры по исправлению положения и исправление состояния будут автоматически направлены в соответствующее агентство. В Калифорнии это будет передано Калифорнийскому совету по воздушным ресурсам (CARB). Если исправление не будет внесено в установленный срок, может быть вынесено предписание.

Использование OBDIII изучалось в нескольких штатах, включая Калифорнию, в рамках пилотных программ. Участвующие автомобили оснащаются соответствующим передатчиком.

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

EOBD и HDOBD
Европейский эквивалент OBDII называется EOBD и применяется ко всем легковым автомобилям категории M1 (полная масса автомобиля не более 2500 кг, не более восьми мест). Это относится к автомобилям с бензиновым и дизельным двигателем. Технические характеристики EOBD аналогичны OBDII, с теми же сигнальными протоколами и диагностическим разъемом.

В дополнение к OBDII и EOBD, HDOBD был выпущен для грузовиков средней и большой грузоподъемности в США. и грузовики средней грузоподъемности. ( Рисунок 3 ).

Рисунок 3: Большегрузные автомобили используют 6-контактный (J1708) или 9-контактный (J1939) разъем для реализации HDOBD, в то время как стандартный разъем OBDII (показан справа) используется всеми другими транспортными средствами. (Изображение: DriveELD)

Резюме
Системы OBD появились с появлением компьютерных процессоров в автомобильных системах для мониторинга производительности системы. Эти системы изначально контролировали состояние транспортного средства, а теперь предлагают комплексный мониторинг контроля выбросов.

Стандарты OBDII, установленные в Калифорнии, с тех пор были приняты по всей территории США. Существуют специальные реализации ODB для грузовиков средней и большой грузоподъемности. В будущем ODBIII добавит к этим системам возможности удаленного мониторинга.

Каталожные номера

• Идентификация типа диагностического порта, DriveELD
• Внедрение и проверка решения протокола SAE J1850 (VPW) для диагностических приложений, Международный исследовательский журнал инженерии и технологий
• Информационный бюллетень по системам бортовой диагностики II (OBD II), Калифорнийский совет по воздушным ресурсам
• Бортовая диагностика, Википедия
• Что такое ODB?, SMLease Design

Стандарты выбросов: США: Бортовая диагностика

• Введение
• MIL и требования к коду неисправности
• Мониторинг
• Критерии неисправности
• Требования стандартизации

Введение

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

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

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

• Калифорния БД и
• Федеральное агентство по охране окружающей среды OBD .

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

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

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

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

Мониторинг

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

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

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

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

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

90 230

Таблица 1
Требования к мониторингу OBD-систем штата Калифорния

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

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

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

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

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

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

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

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

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

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

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

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

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