Information Technology Reference
In-Depth Information
Three hybrid-operating modes were determined for which four required torques were
calculated, which were Motor Torque Only, Engine Torque Only, Motor Torque Ar-
bitrated, and Engine Torque Arbitrated. This block also calculated the regenerative
brake energy available during different vehicle operation scenarios. The Measure-
ment validity algorithm block was designed to determine the validity of the sensor
measurement. Sensors measurements related to a cooling system were forwarded to
the cooling system algorithm control block to keep the system within a specified
temperature range.
During the Design phase, elaborate discussions were held while reviewing the
current market demand and trend keeping in mind core requirements (i.e., fuel cost
and its availability in the United States). Also, various energy storage solutions
were discussed for day-to-day workability for a given vehicle platform and the
hazard it posed to operator, passenger, the public, and the environment. Keeping
all these things in mind, the final architecture was determined and designed. Next, a
real-time operating system, application development environment, coding language,
boundaries of various subsystems, partitions, and its overlaps were discussed and
finalized.
DFSS Optimize Phase—
Here details of the software implementation and the code
itself are not at the center of the discussion because the intention is to evaluate the
software process and its effectiveness on the software product quality and reliability
and not on the coding and implementation details. Also, in this particular software
development, operating systems as well as lower layer software development were
used from previously designed, developed, and tried out concepts. It was decided to
prototype most concepts by hand coding in C
. Proprietary compilation tools and to
build environment were chosen to develop the software. Detail logs were maintained
for the time consumed as well as for the type and number of errors injected and
removed during the software code, compile, integration, and testing phases.
The system was divided into subsystem modules, and the best-suited knowledge-
able team member was chosen to work on the given software (algorithm) modules.
The coder on a bench primarily carried out unit testing while separate personnel
were engaged to write test cases during the bottom-up integration testing, validation
testing, and system testing. Scripts were prepared for reducing testing errors and
to improve quality. Automatic bench testing was carried out on black box testing
and white box testing method concepts while carrying out hardware-in-loop testing.
Test logs were submitted to the coder for review. Final reviews were held with the
cross-functional team.
The Time Recording Log, Defect Recording Log, and PSP Project Plan Summary
were used to determine Planned, Actual, To Date, and To Date% PSP process pa-
rameters during this project. In this case, PSP processes results were planned for 20
persons for 20 weeks, whereas in actuality, 22 persons for 26 weeks were required to
work on this project. Their combined efforts in terms of time, defects injected, and
defects removed were logged. Also, defects were identified and removed related to
code errors, compile errors, and testing errors. All these details were logged as shown
in Table 10.6. For Table 10.6 and Table 10.7 calculations, please refer to Appendix
10.A1, 10.A2, and 10.A3.
++
Search WWH ::
Custom Search