Search Results

The Body Control Module (BCM) is a very large integration site for vehicle features and functions (e.g., Locking, Alarms, interior lighting, exterior lighting, etc…). Every few years the demand to add more feature/functions and integrate more vehicle content increases. The expectation of the 2013 MY (model year) BCM, was to double the feature content and use it globally. The growth in 3 years of feature/function content was huge number that grew from 150 to over 300. This posed a major challenge to the software development team based on the methods and process that were deployed at the time. This paper cites the cultural and technology changes that were overcome when Ford Motor Company partnered with Tata Consultancy Services to help manage and define this new software engineering development methodology. The process of getting from a vague description of a new body module feature to a saleable product, presents several very challenging problems.

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.

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.