Luft- und Raumfahrt
Innovationen und bereichsübergreifendes, synchronisiertes Programmmanagement
Ford Motor Company offers a variety of cars, trucks, SUVs and many other products and services under the brands Ford, Lincoln, Mercury, Volvo and Mazda.
Innovation in the auto industry increasingly involves software and electronics. “The standard estimate is that 60 percent of vehicle innovation is now software and electronics, but we tend to believe it is even higher than that,” says Patrick Milligan, Ford’s senior manager for vehicle solutions. Ford’s Sync feature is a perfect example. This is an optional, in-car communications and entertainment system that gives drivers hands-free, voice-activated control over their mobile phones and digital music players.
The growing prevalence of software and electronics in cars has huge implications for the OEMs. One big one involves after-sales activities and controlling warranty costs. Chris Davey, technical leader, Software and Control Systems Engineering at Ford, illustrates this with a common scenario: “The rapid expansion in the software complexity in our vehicles was creating a problem with our dealerships when it came time to replace or repair electronic control units (ECUs) that had a software glitch,” he says. “The traditional approach was a standard hardware replacement where we would actually remove the ECU from the customer’s vehicle and replace it with a new unit. This approach is not a cost-effective solution, but worse is that in the process of removing and replacing an ECU, you might introduce some squeak and rattle type issues into the customer’s vehicle which is absolutely not desirable.” And with features such as Sync needing to keep up with advances in communications and entertainment technology, it would be cost-prohibitive to replace a piece of hardware on the car each time a software update is needed.
The growing amount of software and electronics also brings with it the need to manage a product with a much shorter lifecycle. “Now we need the ability to manage consumer electronics lifecycles, which turn over in six to nine months, alongside the traditional automotive lifecycle of two to three years,” says Davey.
Another implication is that the volume of software needed for each car is growing rapidly. Ford’s 2005 models contain between two and three million lines of code. Current 2007/2008 vehicles have an average of six million lines of code. The company is expecting about 10 million lines of code in its vehicles in 2010. In looking at the development costs for all this software (which is mainly written by outside suppliers), the company has made it a priority to increase the amount of code that gets re-used.
Integrating and then validating all this software, which comes from all three supplier tiers, is another issue. “While the suppliers do some level of component validation, we have to bring that software together and ensure we’ve got the compatibility up front and then drive it to completeness,” Milligan says. This is complicated by another current trend, the growing interdependency in vehicle electronics systems. “Ten or 15 years ago, you would typically have a power train control module, maybe a transmission control module, and perhaps a brake control module,” explains Davey. “Since then, we’ve seen the rapid introduction of distributed functionality where multiple modules are communicating with each other across a network.” A good example is adaptive cruise control, in which brake and throttle control modules must interact. “Today, on some of the high-end vehicles, there are 50 to 70 modules on the network and dependencies involving probably 60 to 70 percent of those modules,” Davey adds. When software for one module is updated, the OEM must be able to understand the impact of that change on the other modules.
These issues required Ford to “come up with a new way of doing business, a new way of testing, validating and managing the software content that goes on our vehicles,” notes Milligan. “This has been a key deliverable affecting future quality as well as the future cost of our products.”
Ford is meeting these challenges with the In Vehicle Software (IVS) program based on the Teamcenter digital lifecycle management solution from Siemens PLM Software. The company already had a large Teamcenter implementation managing its mechanical development efforts, and its satisfaction with Siemens as a partner played a large role in the choice of Teamcenter for the IVS release program. “Another key reason we built IVS on the Teamcenter platform was to ensure a scalable solution that we can use globally,” says Martin Baker, global manager, Software, CAE and Process, Methods and Tools at Ford. Today, Ford brands in North America, Europe, Asia Pacific and Australia are using the IVS system.
Essentially, Ford and Siemens PLM Software applied to software some of the same practices – such as configuration management and options and variants – that make PLM effective at managing mechanical systems. With software, each file is similar to a part in the mechanical world. What PLM does is make it possible to relate that software file to the vehicle usage, model and platform it is used in. IVS also makes it possible to understand important attributes about the software file such as programming protocols, network protocols, memory sizes, disk file sizes, memory address space of hardware and so on. Validation algorithms can report discrepancies between engineering metadata, software files and their use in service.
Because much of Ford’s software development is done by suppliers all over the world, suppliers use Teamcenter to check software files for common problems automatically when they are uploaded. This helps detect bad software files at the source and get them corrected before they are distributed further. Issues such as header information, memory size consumed, format of the binary file, binary file part number, certification document, test cases and configuration file are checked against the set of requirements. The structured lifecycles introduced in Teamcenter ensure that changes (to address field concerns) are audited in the system from early detection of errors to final engineering resolution.
IVS takes advantage of the Teamcenter systems engineering functionality to solve the problem of communication between ECUs by monitoring and tracking software dependencies. Teamcenter identifies where a particular software component is being used: in which vehicle programs, in which series, in which variants of those programs and in which global locations. The manufacturing data model in IVS tracks information for in-plant flashing, ensuring that correct software assemblies are flashed during manufacturing within the context of plant, program, variant and ECU type.
This has two major benefits. First, it enables Ford to perform impact studies whenever a software change is made. The other benefit is that Ford can now trace the ECUs to an individual customer’s vehicle by the vehicle identification number (VIN).
Teamcenter also feeds the download to service centers in North America, which then gets broadcast to all 20,000 service stations. So whenever a change is required, it becomes a lot easier to communicate this change. “This is a powerful capability,” says Davey. “If a customer’s vehicle is returned to the dealership with a specific concern that cannot be resolved at the dealership, the VIN can then be used to retrieve the complete software bill of material for that vehicle using tools from our customer service division.”
The ability to trace individual software component items is also increasing the amount of software re-use across the global vehicle product line. “In the past, we would recreate and reestablish the software for each individual brand and each vehicle program,” says Davey. “Software re-use is one of the major opportunities we see for the automotive industry. One of the strengths of Teamcenter is how it promotes information re-use. The Teamcenter solution allows us to fully re-use software components without any changes.”
The third benefit of the IVS project is the ability to update vehicle electronics by simply reprogramming the software. “Between IVS and the fact that we can now afford to put flash memory on virtually all of our control units, we can now reprogram in the field,” says Baker. Since reprogramming a controller is much quicker than a hardware replacement, this reduces the cost of repairs. It also eliminates concerns about a part being out of stock, or the customer having to leave the car overnight, or the introduction of a squeak or rattle during the repair. In North America alone, the flash reprogramming capability has saved Ford a great deal of money in the three years the IVS has been in use. “Warranty reduction was a key driver for us and we initially expected savings of between $1 and $5 million per year," adds Baker. "But in three years, we’ve avoided more than one hundred million dollars worth of module replacements by taking advantage of IVS to reflash modules in the field.”
Precise software tracking also reduces the number of unnecessary repairs. Now, when a vehicle comes into the dealership, service can interrogate the vehicle, identify exactly which software is on the vehicle at that time, and use that information to determine whether or not that particular vehicle requires a service. “We can actually target that at the level of an individual vehicle. That has certainly proved useful in filtering out unnecessary repairs that would have taken place under the old system,” Baker adds.
Today’s innovation trends require that the software development lifecycle is given equal importance to the mechanical lifecycle. This is now the case at Ford. “All the OEMs are dealing with these same challenges and mechatronics is a key issue that the automotive industry must deal with in order to remain competitive,” Baker notes. “Tools such as Teamcenter have allowed us to start the merger of the mechanical and the software lifecycles.”