The complexities involved in implementing OBD compliant software can be represented by an iceberg model. Defining specific tests and fault detection criteria is just the tip. The bulk of the task occurs once a fault condition has been detected. OBD legislation precisely defines how the fault and associated information should be stored and reported using defined constructs and communication protocols. These tasks require specialist skills and typically over 10 man-years of effort to go from analyzing legislated specifications to a compliant software implementation. Systems engineers can now focus on their area of expertise by defining specific tests and fault detection criteria. The OBD Infrastructure software handles the complexities of managing fault handling such as memory management, communication protocols for service tool interface, Diagnostic Trouble Code (DTC) life-cycle management and security on any system and meeting mandatory specifications when required.
Guiding OBD Implementation
Developers are guided through the OBD implementation by two key product elements:
Libraries of configurable software
OBD implementation requires precisely defined constructs for fault handling and reporting, including:
- Diagnostic trouble Codes (DTC)
- Freeze-frames
- Diagnostic Monitor Entities (DME)
- Diagnostic Test Entities (DTE)
- In-Use Performance Ratios (IUPR)
The libraries contain these constructs as a C-code functions or configurable Simulink blocks that guide their correct addition to the control system. Interactive dialogues prompt for correct data given the compliance selected.
Intelligent software build system
The developer can add OBD functionality to each system test independently and rely on the Intelligent build system to take on the highly complex task of optimizing the entire system for:
- Control vs platform software partition
- ECU performance
- Software code size
- Non-volatile memory usage
OBD Standards Support
Allowed emissions are continuously being reduced and the scope of applicable vehicles is being increased. Within the decade legislation will extend to include hybrid, alternative fuel, off-highway, motorcycles and marine applications. The OB|D Infrastructure product has the flexibility to support all major proprietary and legislative OBD requirements. Dana’s experts monitor the leading regulatory bodies:
- California Air Resources Board
- US Environmental Protection Agency
- European Union directive
And communication standards:
- Light duty vehicle-s (ISO 15765)
- Heavy duty (SAE J1939)
On which global standards are based.
Features
The four key aspects of the OBD Infrastructure software that accelerate the development of OBD enabled ECU software are:
Auto-generated compliant service requests for:
- Passenger car- ISO 15765 (J1979, KW200-3, UDS)
- Heavy Duty- J1939 Diagnostic Messages
- Vendor specific service requests
Auto-generated standard communications for:
- Passenger car- ISO15765 protocols
- Heavy Duty- SAE J1939 protocols
Guided OBD Implementation using:
- Configurable Simulink blackest (or C-API)
- Templates for complaint Trouble Codes
- Test Entities, Test Monitors
- Performance Ratios, Freeze-frames
- Templates for vendor specific requirements
- Configurable legislative compliance for
- European and CARB emissions standards
Intelligent build system optimization:
- Analyses entire application
- Partitions Application vs Platform software
- Implements required OBD services
- Builds efficient NVM data structures
- Draws on library of 100+ complaint functions