Что такое управление данными? | Определение, важность, & процессы
Перевод этой веб-страницы выполнен машинными средствами. SAP не предоставляет никаких гарантий правильности или полноты машинного перевода. Оригинальную английскую веб-страницу можно найти с помощью карты мира в правом верхнем углу этой страницы.
Данные играют важную роль в работе и функционировании любого бизнеса. Компаниям необходимо уметь извлекать из данных информацию и находить ценные сведения, отделяя их от «шума», который создают различные системы и технологии, поддерживающие современную глобальную экономику с высоким уровнем взаимосвязей. Таким образом, роль данных невозможно переоценить. Но сами по себе данные бесполезны. Компаниям необходимы эффективная стратегия, стратегическое управление и модель управления данными, позволяющие использовать все формы данных для практического и эффективного применения в цепочках поставок, сетях сотрудников, экосистемах клиентов и партнеров — и это далеко не все.
Определение и процесс управления данными
Управление данными — это практика сбора, организации и доступа к данным для повышения производительности, эффективности и принятия решений. Учитывая ключевую роль, которую сегодня играют данные в бизнесе, для каждой компании, независимо от размера и отрасли, важны надежная стратегия управления данными и современная система управления данными.
Процесс управления данными охватывает широкий спектр задач и процедур, таких как:
- Сбор, обработка, проверка и хранение данных
- Интеграция различных типов данных из разрозненных источников, включая структурированные и неструктурированные данные
- Обеспечение высокой доступности данных и восстановления после сбоев
- Регулирование использования данных и доступа к ним людей и приложений
- Защита и обеспечение безопасности данных, а также поддержка конфиденциальности данных
Почему управление данными играет такую важную роль?
Любое приложение, аналитическое решение или алгоритм, применяемые в бизнесе (правила и связанные с ними процессы, которые позволяют компьютерам решать проблемы и выполнять задачи), зависят от наличия беспрепятственного доступа к данным.
Система управления данными призвана обеспечить безопасность, доступность и точность данных. Но на этом преимущества управления данными не заканчиваются.
64,2
зеттабайт
цифровых данных, созданных в 2020 году,
80-90
%
данных — это неструктурированная информация
Превращение больших данных в ценный бизнес-актив
Слишком большой объем данных может оказаться бесполезным при отсутствии должного управления. Но с помощью правильных инструментов большие данные можно использовать для расширения возможностей компаний благодаря получению более глубоких знаний и более точных прогнозов. Этот подход позволяет компаниям лучше понимать, чего хотят клиенты, и помогает им обеспечивать безупречное качество клиентского опыта на основе полученных сведений. Его также можно применить для разработки новых бизнес-моделей на основе данных — таких как предложения услуг на базе получаемых в реальном времени данных Интернета вещей и данных с датчиков — которые становятся возможными и очевидными именно благодаря способности анализировать и интерпретировать большие данные.
Большие данные представляют собой чрезвычайно крупные массивы данных, которые часто характеризуются пятью признаками: огромный объем собираемых данных, разнообразие типов данных, скорость поступления, достоверность данных и их ценность.
Не секрет, что организации, активно использующие данные, обладают значительным конкурентным преимуществом. Благодаря современным инструментам компании могут управлять большим объемом данных из большего количества источников, чем было возможно ранее. Они также могут продуктивно использовать множество различных типов данных, структурированных и неструктурированных, в режиме реального времени, включая данные устройств Интернета вещей, видео- и аудиофайлы, записи пользовательской активности и комментарии в социальных сетях, открывая новые возможности для монетизации данных и использования их в качестве актива.
Создание фундамента данных для цифровой трансформации
Часто говорят, что данные — это плоть и кровь цифровой трансформации, и это действительно так.
Искусственный интеллект (ИИ), машинное обучение, «Индустрия 4.0», расширенная аналитика, Интернет вещей и интеллектуальная автоматизация — всем этим технологиям для работы требуется большое количество своевременных, точных и безопасных данных.
После пандемии COVID-19 важность данных и технологий, основанных на данных, еще больше возросла. Многие компании испытывают острую необходимость в более эффективном использовании своих данных, в том числе для прогнозирования будущих событий, быстрой смены курса и обеспечения устойчивости планов и бизнес-моделей.
Например, для машинного обучения требуются очень большие и разнообразные наборы данных для «обучения», выявления сложных закономерностей, решения проблем, поддержки актуального состояния и эффективной работы моделей и алгоритмов. Расширенная аналитика (которая часто использует машинное обучение) также зависит от огромного объема высококачественных данных для получения актуальных и действенных выводов, на которые можно с уверенностью опираться.
Интернет вещей и промышленный Интернет вещей работают на постоянном потоке данных, поступающих от устройств и датчиков со скоростью миллион миль в минуту.
Общим знаменателем в любом проекте цифровой трансформации являются данные. Чтобы преобразовать процессы, воспользоваться преимуществами новых технологий и стать интеллектуальными предприятиями, компаниям необходим прочный фундамент для работы с данными. Одним словом, им нужна современная система управления данными.
Выживание любого бизнеса в будущем будет зависеть от наличия гибкой архитектуры, ориентированной на данные и способной реагировать на постоянные изменения.
Дональд Файнберг (Donald Feinberg), вице-президент Gartner
Обеспечение соблюдения законов о конфиденциальности данных
Эффективное управление данными также необходимо для соблюдения национальных и международных законов о конфиденциальности данных, таких как Генеральный регламент ЕС о защите персональных данных (GDPR) и Закон об обеспечении конфиденциальности потребителей штата Калифорния в США, а также требований конкретной отрасли к конфиденциальности и безопасности.
Если же требуется доказать или проверить соблюдение этих мер защиты, наличие надежных политик и процедур управления данными совершенно необходимо.
Системы и компоненты управления данными
Системы управления данными строятся на платформах управления данными и включают ряд компонентов и процессов, которые работают вместе, позволяя извлекать пользу из данных. К ним относятся системы управления базами данных, хранилища и озера данных, инструменты интеграции данных, аналитика и многое другое.
Системы управления базами данных (СУБД)
Существует несколько разных типов систем управления базами данных. К наиболее распространенным относятся системы управления реляционными базами данных (RDBMS), объектно-ориентированные системы управления базами данных (OODMBS), базы данных in-memory и столбцовые базы данных.
- Система управления реляционными базами данных (RDBMS). RDBMS — это система управления базами данных, которая содержит определения данных, предназначенные для того, чтобы программы и системы извлечения могли ссылаться на элементы данных по имени, а не описывать каждый раз структуру и местоположение данных.
Основанные на реляционной модели, системы RDBMS также поддерживают отношения между элементами данных, что улучшает доступ и позволяет избежать дублирования. Например, базовое определение товара и его характеристики сохраняются однократно и связываются со строками деталей заказа клиента и таблицами цен. - Объектно-ориентированная система управления базами данных (OODBMS). OODBMS воплощает другой подход к определению и хранению данных, разработанный и используемый разработчиками системы объектно-ориентированного программирования (OOPS). Данные хранятся в виде объектов, самодостаточных и самоописываемых сущностей, а не в таблицах, как в RDBMS.
- База данных in-memory (IMDB) хранит данные в оперативной памяти компьютера (ОЗУ), а не на диске. Извлечение из памяти происходит намного быстрее, чем считывание из дисковой системы, поэтому базы данных in-memory обычно используются в приложениях, требующих быстрого отклика. Например, если ранее для составления отчета требовалось несколько дней, то теперь нужные данные можно получить и проанализировать за считанные минуты, если не секунды.
- Столбцовая база данных. В такой базе хранятся группы связанных данных («столбцы информации»), обеспечивая быстрый доступ. Подобные БД используются в современных бизнес-приложениях с технологией in-memory и во многих автономных приложениях хранилищ данных, где важна скорость поиска (по ограниченному диапазону данных).
Хранилища и озера данных
- Хранилище данных. Хранилище представляет собой централизованный репозиторий данных, накопленных из множества различных источников для целей отчетности и анализа.
- Озеро данных. Озеро данных — это огромный пул данных, хранящихся в необработанном или естественном формате. Озера данных обычно используются для хранения больших данных, включая структурированные, неструктурированные и полуструктурированные данные.
Управление основными данными (MDM)
Управление основными данными — это дисциплина создания единого достоверного справочника (единой версии достоверных данных) для всех важных бизнес-данных, таких как данные о продуктах, клиентах, активах, финансах и т.
д. Управление основными данными помогает компаниям не использовать несколько потенциально противоречивых версий данных в различных областях бизнеса, включая процессы, операции, аналитику и отчетность. Три ключевых компонента эффективного управления основными данными (MDM): консолидация данных, управление данными и управление качеством данных.
Технологическая дисциплина, в рамках которой бизнес- и ИТ-подразделения сотрудничают для обеспечения единообразия, точности, ответственности, семантической непротиворечивости и подотчетности официальных, совместно используемых основных данных.
Определение MDM от Gartner
Управление большими данными
Для управления большими данными были разработаны новые типы баз данных и инструментов — огромные объемы структурированных, неструктурированных и полуструктурированных данных, приносящих пользу компаниям в настоящее время. В дополнение к высокоэффективным методам обработки и облачным функциям для обработки объема и скорости были разработаны новые подходы к интерпретации и управлению разнообразием данных.
Чтобы инструменты управления данными могли понимать различные виды неструктурированных данных и работать с ними, например, новые процессы предварительной обработки используются для идентификации и классификации элементов данных для упрощения хранения и извлечения.
Интеграция данных
Интеграция данных — это практика получения, преобразования, объединения и предоставления данных там и тогда, где и когда они необходимы. Такая интеграция осуществляется в масштабе предприятия и выходит за его пределы — включая партнеров, а также сторонние источники данных и сценарии использования — для удовлетворения требований всех приложений и бизнес-процессов к потреблению данных. Методы интеграции включают массовое/пакетное перемещение данных, извлечение, преобразование, загрузку (ETL), сбор данных об изменениях, репликацию данных, виртуализацию данных, интеграцию потоковых данных, координацию данных и многое другое.
Стратегическое управление данными, безопасность и соблюдение требований
Стратегическое управление данными (data governance) определяет правила и сферы ответственности, цель которых состоит в обеспечении доступности, качества, нормативного соответствия и безопасности данных в масштабе организации.
Стратегическое управление данными создает инфраструктуру и определяет лиц (или должности) в организации, которые имеют полномочия и несут ответственность за обработку и защиту конкретных видов и типов данных. Стратегическое управление данными является ключевым компонентом обеспечения нормативного соответствия. Системы берут на себя техническую часть хранения, обработки и безопасности данных. Но именно люди — члены команды, ответственной за управление данными — гарантируют, что данные изначально являются точными, а затем должным образом обрабатываются и защищаются перед вводом в систему, во время использования и при извлечении из системы для использования или хранения в другом месте. Стратегическое управление данными определяет, как именно ответственные лица используют процессы и технологии для управления данными и их защиты.
Несомненно, безопасность данных является серьезной проблемой в современном мире хакеров, вирусов, кибератак и утечек данных. Хотя функции обеспечения безопасности встроены в системы и приложения, стратегическое управление данными призвано обеспечить правильную настройку и администрирование этих систем для защиты данных, а также соблюдение процедур и обязанностей по защите данных за пределами систем и баз данных.
Бизнес-аналитика (BI) и аналитика
Большинство систем управления данными включают в себя базовые инструменты поиска данных и создания отчетов, а многие из них оснащены или поставляются в комплекте с мощными приложениями для поиска, анализа и создания отчетов. Приложения для создания отчетов и аналитики также доступны от сторонних разработчиков; они обычно включаются в пакет приложений в качестве стандартной функции или дополнительного модуля с расширенной функциональностью.
Мощь современных систем управления данными в значительной степени определяется специальными средствами поиска, которые позволяют пользователям с минимальным уровнем подготовки создавать собственные экранные функции поиска нужных данных и печатные отчеты с чрезвычайно гибкими возможностями форматирования, вычислений, сортировки и сводок. А профессионалы могут использовать эти же средства или более сложные наборы аналитических инструментов для проведения самых разнообразных расчетов, сравнений, вычислений из высшей математики и форматирования.
Новые аналитические приложения способны интегрировать традиционные базы данных, хранилища и озера данных, позволяя объединять большие данные с данными бизнес-приложений для повышения качества прогнозирования, анализа и планирования.
Что такое корпоративная стратегия управления данными и зачем она вам нужна?
Многие компании пассивно относились к стратегии управления данными, принимая все, что поставщик бизнес-приложений встроил в их системы. Но сейчас этого уже недостаточно. Учитывая взрывной рост объемов данных и их важность для работы каждого предприятия, насущной необходимостью становится более активный и комплексный подход к управлению данными. С практической точки зрения это означает подготовку к разработке стратегии управления данными, которая:
- Определяет конкретные типы данных, которые нужны вашей компании и будут использоваться ею
- Распределяет ответственность за каждый тип данных
- Устанавливает процедуры, регулирующие получение, сбор и обработку этих данных
Одно из ключевых преимуществ стратегии и инфраструктуры управления корпоративными данными заключается в том, что она охватывает всю организацию, координируя все действия и решения для поддержки цели предприятия, заключающейся в эффективном и результативном предоставлении клиентам качественных продуктов и услуг.
Наличие всеобъемлющей стратегии управления данными и комплексная интеграция данных устраняют разрозненность информационных активов. Это позволяет каждому отделу, менеджеру и сотруднику видеть и понимать свой вклад в успех компании, а также координировать свои решения и действия с глобальными целями.
Разработка стратегии управления данными для вашего бизнеса
Посмотрите модули нашего мастер-класса по стратегии управления данными, ориентированного на результат, бесплатно онлайн.
Эволюция управления данными
Эффективное управление данными уже более 50 лет имеет решающее значение для успешной работы любой компании. Оно поддерживает целый спектр функций — от повышения точности информационной отчетности, выявления тенденций и принятия более взвешенных решений до подпитки цифровой трансформации и внедрения новых технологий и бизнес-моделей. Данные стали новым видом капитала, и дальновидные организации всегда находятся в поиске новых оптимальных способов использования данных в своих интересах.
Вот некоторые из последних тенденций в области современного управления данными, за которыми важно следить и изучать их применимость для вашего бизнеса и отрасли:
- Фабрика данных. Большинство организаций сегодня работают с разнообразными типами данных, развернутых на локальных и облачных ресурсах, и используют несколько систем управления базами данных, технологий обработки и инструментов. Фабрика данных, представляющая собой индивидуально настроенное сочетание архитектуры и технологий, применяет динамическую интеграцию и координацию данных для обеспечения беспрепятственного доступа к данным и их совместного использования в распределенной среде.
- Управление данными в облаке. Многие компании переносят в облако часть своей платформы управления данными или всю платформу. Облачные механизмы управления данными обладают всеми преимуществами облачных технологий, включая масштабируемость, повышенную безопасность данных, улучшенный доступ к данным, автоматическое резервное копирование и аварийное восстановление, экономию средств и многое другое.
Популярность облачных баз данных и решений по модели «база данных как услуга» (DBaaS), облачных хранилищ данных и облачных озер данных постоянно растет. - Дополненное управление данными (augmented data management) — одна из новых тенденций. Gartner считает, что в 2022 году эта тенденция обладает огромным потенциалом прорывных изменений. Дополненное управление данными использует искусственный интеллект и машинное обучение, чтобы сделать процессы управления данными самонастраивающимися и саморегулирующимися. Дополненное управление данными автоматизирует все процессы, от обеспечения качества данных и управления основными данными до интеграции данных, высвобождая ресурсы квалифицированных технических специалистов и позволяя им сосредоточиться на выполнении более важных задач.
В течение 2022 года объем ручных задач по управлению данными сократится на 45% благодаря машинному обучению и автоматизированному управлению уровнем обслуживания.
— Gartner
- Дополненная аналитика.
Дополненная аналитика — еще одна ведущая технологическая тенденция, выявленная Gartner — уже стала реальностью. Она использует искусственный интеллект, машинное обучение и обработку текстов на естественном языке (NLP) не только для автоматического поиска наиболее важных сведений, но и для демократизации доступа к расширенной аналитике, благодаря чему каждый сотрудник, а не только специалисты по аналитической обработке данных, сможет задавать вопросы о своих данных и получать ответы в формате естественного диалога.
Другие термины и тенденции в области управления данными.
Заключение
Мы знаем, что информация извлекается из данных. А если информация — это сила, то эффективное управление данными и их результативное использование вполне может стать суперсилой вашей компании. Такой подход позволяет по-новому взглянуть на обязанности по управлению данными и роль аналитиков баз данных, превращая их в лидеров процесса изменений, продвигающих освоение облачных решений, использование новых тенденций и технологий и обеспечивающих стратегическую ценность для бизнеса.
Решения для управления данными и базами данных
SAP помогает управлять корпоративными данными и интегрировать их.
Подробнее
Другие материалы серии
Новостная рассылка SAP Insights
Идеи, которые вы больше нигде не найдете
Зарегистрируйтесь, чтобы получить дозу бизнес-информации и аналитики, доставляемую прямо в ваш почтовый ящик.
Другие материалы
PostgreSQL — популярная свободная объектно-реляционная система управления базами данных
PostgreSQL — это популярная свободная объектно-реляционная система управления базами данных. PostgreSQL базируется на языке SQL и поддерживает многочисленные возможности.
Преимущества PostgreSQL:- поддержка БД неограниченного размера;
- мощные и надёжные механизмы транзакций и репликации;
- расширяемая система встроенных языков программирования и поддержка загрузки C-совместимых модулей;
- наследование;
- легкая расширяемость.
- Нет ограничений на максимальный размер базы данных
- Нет ограничений на количество записей в таблице
- Нет ограничений на количество индексов в таблице
- Максимальный размер таблицы — 32 Тбайт
- Максимальный размер записи — 1,6 Тбайт
- Максимальный размер поля — 1 Гбайт
- Максимум полей в записи250—1600 (в зависимости от типов полей)
Функции в PostgreSQL являются блоками кода, исполняемыми на сервере, а не на клиенте БД. Хотя они могут писаться на чистом SQL, реализация дополнительной логики, например, условных переходов и циклов, выходит за рамки собственно SQL и требует использования некоторых языковых расширений. Функции могут писаться с использованием различных языков программирования. PostgreSQL допускает использование функций, возвращающих набор записей, который далее можно использовать так же, как и результат выполнения обычного запроса.
Функции могут выполняться как с правами их создателя, так и с правами текущего пользователя. Иногда функции отождествляются с хранимыми процедурами, однако между этими понятиями есть различие.
Триггеры в PostgreSQL определяются как функции, инициируемые DML-операциями. Например, операция INSERT может запускать триггер, проверяющий добавленную запись на соответствия определённым условиям. При написании функций для триггеров могут использоваться различные языки программирования. Триггеры ассоциируются с таблицами. Множественные триггеры выполняются в алфавитном порядке.
Механизм правил в PostgreSQL представляет собой механизм создания пользовательских обработчиков не только DML-операций, но и операции выборки. Основное отличие от механизма триггеров заключается в том, что правила срабатывают на этапе разбора запроса, до выбора оптимального плана выполнения и самого процесса выполнения. Правила позволяют переопределять поведение системы при выполнении SQL-операции к таблице.
Индексы в PostgreSQL следующих типов: B-дерево, хэш, R-дерево, GiST, GIN. При необходимости можно создавать новые типы индексов, хотя это далеко не тривиальный процесс.
Многоверсионность поддерживается в PostgreSQL — возможна одновременнуя модификация БД несколькими пользователями с помощью механизма Multiversion Concurrency Control (MVCC). Благодаря этому соблюдаются требования ACID, и практически отпадает нужда в блокировках чтения.
Расширение PostgreSQL для собственных нужд возможно практически в любом аспекте. Есть возможность добавлять собственные преобразования типов, типы данных, домены (пользовательские типы с изначально наложенными ограничениями), функции (включая агрегатные), индексы, операторы (включая переопределение уже существующих) и процедурные языки.
Наследование в PostgreSQL реализовано на уровне таблиц. Таблицы могут наследовать характеристики и наборы полей от других таблиц (родительских).
При этом данные, добавленные в порождённую таблицу, автоматически будут участвовать (если это не указано отдельно) в запросах к родительской таблице.
Использование в веб-проектах
В разработке простых сайтов PostgreSQL используется несколько реже, чем MySQL / MariaDB, но всё же эта пара с заметным отрывом опережает по частоте использования остальные системы управления базами данных. При этом в разработке сложных сайтов и веб-приложений PostgreSQL опережает по использованию MySQL и MariaDB. Большинство фреймворков (например, Ruby on Rails, Yii, Symfony, Django) поддерживают использование PostgreSQL в разработке.
Введение в бортовую диагностику (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 вносились поправки 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 фунтов.
Полная масса 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).
| Система/компонент | Параметр, требующий мониторинга |
|---|---|
| Топливная система | Регулятор давления в топливной системе |
| Количество инъекций | |
| Момент впрыска | |
| Контроль обратной связи | |
| Осечка | Обнаружение постоянных пропусков зажигания |
| Определение % пропусков зажигания на 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)
- Удаление диагностической информации, связанной с выбросами: диагностическая информация, связанная с выбросами, может быть удалена по команде сканирующего прибора (универсального или расширенного) или если питание бортового компьютера отключено.
Недостатки
Системы БД все еще могут быть условно сертифицированы, даже если они не соответствуют одному или нескольким юридическим требованиям, изложенным в правилах, и производитель добросовестно приложил усилия для их соблюдения.