Search Results

The embedded software development process for electronic engine controls is undergoing rapid changes and advancements. A large number of software process improvement (SPI) initiatives have recently commenced, partly in response to emerging technologies involving code generation [1, 2, 3 and 4] and automated testing [5,6]. The ability to generate and test embedded code using computer automation is certainly a tremendous advancement and worthy of review by SPI teams. However, there are other important software engineering tasks that also need consideration including verification and validation, configuration management, and documentation. Powerful computer automated tools are available for nearly every one of these tasks. This makes it easy for SPI teams to get caught up in the excitement of a tool's individual capabilities, without paying attention to its impact on the process as a whole. A software engineering framework consists of a process with methods and tools.

Software development schedules are being stretched to the breaking point across the automotive industry, while quality requirements are skyrocketing. Improved specifications help in the development of quality software, but further steps are warranted. Software testing strategies are being examined across the industry, with special attention to the manner by which they fit into the software development process. This document presents one such strategy, with special emphasis on an often-overlooked step in software testing: the Unit Test. The cost to detect and fix a bug at the unit level is startlingly less than at higher levels of test. One reason for this is that unit test is generally the only level at which unusual and unexpected conditions are systematically tested. Untested unexpected conditions, when detected by the consumer, often result in emergency changes to the product, and can even cause a general recall upgrade.

Testing of automotive real-time embedded systems software, the primary way software defects are detected, is only effective if it is comprehensive. Test coverage is a measure of the completeness of the test cases. If used properly, in conjunction with other software quality measures and good coding style, software test coverage can provide a reasonable quantitative indication of the sufficiency of a defined set of tests. Not using software test coverage metrics is like testing in the dark. With over one hundred types of testing coverage measures, choosing the right one for a particular automotive real-time embedded controller application can be challenging. This paper reviews the commonly used test coverage measures in the automotive software industry and focuses on the most important coverage types for the automotive real-time embedded software testing.

Electronic control system manufactures within the off-highway industry are aggressively upgrading their embedded software development processes to include simulation, rapid prototyping, and Hardware-in-loop testing (HIL). However, software life cycle concerns are not always considered during process revolutions such as these, even though most project managers agree that the majority of software costs accrue during maintenance. This paper proposes the use of automated implementation and unit test tools to generate production code and unit test vectors from a graphical representation of the ECU model used during simulation and prototyping. These automated tools not only improve development time but, more importantly, save on maintenance and reuse costs. Another proposal is made herein regarding the use of a new rapid prototyping environment for more accurately accounting for production microcontroller constraints during control algorithm design.