SAE 2014 On-Board Diagnostics Symposium

Technical Session Schedule

Tuesday, September 9

Draft Schedule for On-Board Diagnostics Symposium - Day One
(Session Code: OBD100)

Room TBD  ALL DAY

Time Paper No. Title
8:15 a.m. ORAL ONLY
Welcome & Symposium Opening
Bernard Challen, Shoreham Services
8:30 a.m. ORAL ONLY
Keynote Speaker
Floyd Vergara, California Air Resource Board
9:15 a.m. ORAL ONLY
OBD US Update
Mike Regenfuss, California Air Resources Board
10:00 a.m.
BREAK
10:30 a.m. ORAL ONLY
Chrysler OBD Experiences
This presentation is meant to share one manufacturer’s experiences relative to continuing OBD implementation challenges, OBD global interpretation challenges, OBD approval challenges, OBD best practices, OBD issue disclosure and resolution optimization, outsourcing-related OBD challenges and other important lessons learned.
Hal Zatorski, Chrysler Group LLC
11:15 a.m. ORAL ONLY
Are Hidden Diagnostics Inside a Smart Device Allowed?
Smart Devices contain microprocessors but do not have enough diagnostic content to categorize them as diagnostic emissions critical controllers. The next round of proposed OBD regulations will further define the diagnostic requirements of such devices. This presentation will provide a working definition of a hidden diagnostic. Furthermore, it will illustrate examples of several types of hidden diagnostics and their characteristics in an attempt to determine if they are allowed by the OBD regulations. The intent of the presentation is to teach and inform both vehicle and smart device manufacturers how to identify and characterize hidden diagnostics in order to avoid OBD non-compliant smart device behaviors.
Daniel Grenn, General Motors Vehicle Engineering Cntr.
12:00 p.m. ORAL ONLY
Ford OBD Experiences
Paul A. Baltusis, Ford Motor Co.
12:45 p.m. ORAL ONLY
OBD Exhibitor Introductions
Bernard Challen, Shoreham Services
1:00 p.m. ORAL ONLY
Networking Lunch with Exhibits
2:00 p.m. ORAL ONLY
VW OBD Experiences
Robert Gruszczynski, Volkswagen of America
2:45 p.m. ORAL ONLY
Toyota OBD Experiences
Morton M. Smith, Toyota
3:30 p.m. ORAL ONLY
JLR MAF Sensor Rationality Monitoring
Introduction: In common with a number of manufacturers, for higher output engines JLR has found it necessary to have two separate air intakes, each with its own mass air flow (MAF) sensor.

Problem: On JLR’s eight cylinder engines, the two separate intakes converge to a single throttle. CARB’s OBD II regulation requires that input components be monitored for values that are, “neither inappropriately high nor inappropriately low” and the diagnostic for this compared each MAF sensor reading with half of the modelled engine airflow. This worked well on the initial passenger car applications, but on our SUVs, it must be possible to fit raised air intakes to improve the vehicle’s wading performance, which means that there is some distance between each intake’s entry point. At low engine airflow conditions a crosswind could then create a flow imbalance across the two intakes, which caused a false failure of the MAF sensor monitor.

Development of a Solution: Characterisation of the problem showed that a simple adjustment of the monitor entry conditions would mean blocking out a significant low speed and load area of engine operation, with no guarantee that there wasn’t a customer driving condition somewhere that would still lead to a false failure. Discussing this approach with CARB did not go well, as the MAF is viewed as a key input component. A number of solutions were then proposed and discussed internally, flow splitters, shut off flaps for one side of the system, deleting the MAFs and relying on MAP sensors or even fitting extra, redundant MAFs to provide a crosscheck. The goal was no hardware changes, no changes to the existing sensors and acceptance from CARB. This was achieved by developing a software algorithm that could identify a flow imbalance, but still allow the detection of a biased MAF. For part of the test programme, a proving ground was used with a side wind generator, as this had a good level of repeatability, compared to public roads.
Martin Haggett, Jaguar Land Rover
4:15 p.m.
BREAK
4:45 p.m. ORAL ONLY
Six Sigma Process and Design Methodologies in OBD
Many corporations encourage Six Sigma process and design methodologies to be used in their product development. Some even require certain suppliers to adhere to expectations set forth by Six Sigma. This presentation will provide an overview of Six Sigma usage in On-Board Diagnostics (OBD) development. Specific examples from the various phases of OBD design, implementation, and validation will be described. Lessons Learned will also be discussed, as well as the advantages and disadvantages of various approaches for incorporating Six Sigma into OBD.
Justin Owen, Cummins Inc.
5:15 p.m. ORAL ONLY
Bringing the AUTOSAR Standard into a Gasoline Engine Controller Project – a Comprehensive Analysis for the Diagnostic Event Manager
For more than 10 years the AUTOSAR (AUTomotive Open System ARchitecture) community has been working to standardize Basis Software (BSW) functionality and interfaces in electronic control units in automotive applications. With the latest standard version 4.1 OBD functionality is now covered with many extensions.

However, up to now the Diagnostic Event Manager (Dem) processing results from the monitoring functions (“events”), fault entry handling and several other specific OBD functionality has not been introduced into an engine controller yet. This is mostly due to the many specific requirements of an engine control unit, e.g. for the handling of misfire detection.

The presentation shows the ongoing activities at Bosch to bring the AUTOSAR Dem into an engine controller of a gasoline project together with a customer. It gives insight into the practical work of the analysis of the remaining gaps within the functionality as well as the interfaces to other packages and other features. That is, the current challenge is to identify the necessary features that are needed in the project and to fill these gaps with detailed functionality, e.g. on the synchronized computation of different operation cycles, indicator control, and similar conditions handling.

Most of the functionality is being known from proprietary diagnostic manager solutions. Therein, as a combination with a function inhibition management (AUTOSAR: FiM), extended functionality is already provided – spanning from additional inhibit options up to multiple further attributes of the diagnostic results being reported to the diagnostic manager.

Furthermore, first solutions are introduced and an outline is given on the maturity of these approaches, remaining open topics and the next steps to bring these standardized packages with well defined extensions and modifications into series.
Alexander Hinz, Robert Bosch GmbH