Search Results

Applying good engineering practices to software-intense automotive systems can save automakers millions of dollars in warrantee costs, lost customer loyalty and lawsuits. Carefully crafted development testing could expose non-robust software that fails intermittently when the customer activates the function. The chances are very good the service technician will replace the ECU when the customer brings the vehicle in for repair of the intermittent behavior. These electronic parts are sent to the supplier for analysis. Upwards of 60% of all ECUs analyzed are TNI (Trouble Not Identified) related. This paper elaborates on a method of developmental testing that provides these cost savings. This paper continues to build on concepts discussed in the SAE paper, “The Bus Crusher and The Armageddon Device Part I”. [1] The experiment of subjecting an ECU to several electrical disturbances is explained in detail.

Most testing is done in a clean or static environment. The electrical power is connected to a constant voltage power supply. This is not very representative of the automotive environment. Electrically the automobile is very noisy, has dynamic behavior, and can be difficult to model and emulate. Microprocessors can make mistakes at a rate of 1 million mistakes per second. If we can't test the software 100%, we need methods that will give us some level of confidence that the product is of high quality and will satisfy the customer. The test methods detailed in this paper can help gauge the robustness of the software. These extraordinary tests are not part of standard test methods. Standard test methods use traceability of the functional requirements to develop the test. Each function is tested once per test cycle. Most of these tests are “Happy Path”. [3] Occasionally, failure modes and the effects are included in the test plan.

In an effort to improve the quality of software and take advantage of Lessons Learned, Ford Motor Company has created a generic list of software requirements to help prevent software design errors, mistakes and faults from being delivered to our customer in our vehicles. Ford's intent of publishing these requirements is to provide a basis for an SAE Recommended Practice. Ford's goal is to encourage the software community to participate in the development of a recommended practice that can benefit all software developers. These particular requirements were developed for Automotive Body Features.

This paper introduces several requirements that have been created based on lessons learned at Ford Motor Company. This is not a collection of requirements already addressed by MISRA. These are requirements which address repeated or costly problems that have been observed at Ford Motor Company in their Electronic Body Modules. Real world examples of why they were needed will be highlighted as well as the principles used to create them and confirm compliance. Electronic Body Modules at Ford Motor Company usually control Interior Lighting, Exterior Lighting, Chime, Wipers, Power Mirrors, Power Seats and other features related to passenger comfort. These modules typically use less than 32 K of ROM and are written in C. While some modules are connected to a vehicle network, others are stand-alone.

Customers want new and exciting features in their vehicles. As the cost of implementing features goes down, OEMs (Original Equipment Manufacturers) are eager to provide customers with these new “toys.” Because being “Fast to market” is paramount, there is a tendency to shortcut the development process. If the Customer Requirements are not clearly understood, problems can occur late in the design process. This causes production delays and lost revenues. It is easier and more cost effective to identify and correct problems before finalizing the design. During initial development of a vehicle, engineers are given a list of performance requirements or feature behaviors. Careful analysis of requirements early in the design process will minimize software defects and incorrect behavior. This paper provides an example of Customer requirements and a process to analyze those requirements. The example used is an illuminated entry control system for automotive application.

As vehicle manufactures continue to increase electronic functional content on vehicles; there is an increased demand on software to support these new features. These new features assist the driver in making vehicle operation simpler, more convenient and safer. An example of this is automatic turning on and off of the headlamps. To the human this is a simple task. To a microprocessor this posses some challenges to do the function correctly and not introduce unanticipated behavior. This paper discusses some of the problems observed with automotive embedded software development and suggests simple methods of handling them.