TRW Automotive Develops and Tests Electric Parking Brake
Challenge
Solution
Results
- Test case development time reduced from days to hours
- 100 percent model coverage achieved
- Formal testing begun two months into the project
The electric parking brake (EPB) developed by TRW Automotive, now ZF Friedrichshafen AG, offers many advantages over traditional parking brakes. By eliminating the need for a parking brake lever or pedal, the EPB provides greater flexibility in the vehicle’s interior design. The EPB’s onboard computer can be integrated with the vehicle’s stability control system. For example, it can be configured to release the brake when the vehicle accelerates, activate the brake when the driver’s door opens, and prevent the vehicle from rolling backward when starting from a stop.
Because the EPB is a critical part of the parking application, TRW had to test every operation and branch of the control software. TRW used MathWorks tools for Model-Based Design to model and simulate the control system of the IEC 61508–certified EPB. With Simulink Design Verifier™ TRW engineers automatically generated tests, an approach that helped the group achieve 100 percent coverage of their Simulink® and Stateflow® models.
“Simulink Design Verifier enabled us to bring the formal testing of our software in-house and verify our design in the first phases of development, when defects are easier and less costly to fix,” notes Christoph Hellwig, team lead at TRW.
Challenge
On previous projects, an external vendor manually wrote and performed tests on TRW’s code. Using the test results, TRW developers analyzed and debugged their code. The process was expensive and prone to miscommunication and delays. Further, manual testing left some portions of the designs uncovered by tests. “We decided to bring this process in-house, not only to reduce costs, but also to develop this type of software verification expertise within our organization,” says Hellwig.
TRW sought to improve its test process and provide meaningful and actionable feedback to developers much earlier in the development cycle.
Solution
The software development group at TRW had used MATLAB® and Simulink to develop a detailed software design specification, which enabled them to change their test process.
TRW engineers used Simulink Design Verifier to generate tests that enabled them to meet their customer’s requirement for 100 percent coverage on the EPB control system model.
Ling Zhu, test engineer at TRW, used Simulink Design Verifier to automatically generate tests from the same models that were used for development of code.
The test engineers then ran the generated test cases to review the test results. They also used Requirements Toolbox™ and Simulink Coverage™ to generate model coverage reports that highlighted untested elements of the EPB design and provided developers with insight into areas of the model that were not being exercised. Developers use these reports to shorten the time needed to resolve defects.
Once the test harnesses were complete, the TRW development group converted the specification into a fixed-point model and generated C code. Ling reran the tests generated by Simulink Design Verifier against the C code and compared the test results to identify any problems introduced by the conversion process. This technique made it easy to find time-shift errors in the design as well as unreachable pathways in the code.
TRW is developing a more configurable version of the EPB for the general automotive market, and is expanding its use of Requirements Toolbox and Simulink Coverage to link requirements to its designs, tests, and generated code.
Results
Test case development time reduced from days to hours. “Writing tests for complex models using manual processes required several days of effort,” says Hellwig. “With Simulink Design Verifier, we automatically generate the tests and get reliable, repeatable test results in a few hours. For simpler models that previously required a full day of manual test writing, we have results within a few minutes.”
100 percent model coverage achieved. “We supplemented the automatically generated test cases from Simulink Design Verifier with just a few handwritten tests and attained 100 percent code coverage,” says Hellwig. “With the manual process, we were unable to achieve this level of coverage.”
Formal testing begun two months into the project. “Given the expense of third-party testing, we used to wait until function freeze, or about one year into the project, to begin formal testing,” says Hellwig. “Simulink Design Verifier enables us to perform this testing in-house, so we can provide meaningful feedback to development starting with initial builds, often just two months after the project begins.”