Situation For the next generation body ECU, BMW and
their supplier planned an upgrade to a new, powerful processor. One of the
developers, Hans Sarnowski, had done a lot of work with T1 in the past and
recommended, before the upgrade, to reexamine the upgrade with T1.
Solution With T1, the timing could be precisely analysed
and optimized, so that, in spite of the additional functions, BMW could avoid
the change of processor and the high costs involved with a change of hardware.
Situation For years, Continental pursued a cutting-edge
approach to the subject of embedded timing. Timing measurement data were
systematically collected from all projects and stored in a database. The
scheduling of future projects was developed and verified by extracting this data
and processing it with chronSIM. chronSIM is the scheduling simulation
environment of our partner INCHRON .
The generation of an automatically instrumented software version for timing
measurement consumed around six hours, which posed a real problem due to the
high number of such measurements.
Solution After intensive evaluation of T1, Continental
decided to replace their own, static instrumentation based, solution with
T1. T1.flex permits the dynamic instrumentation of hundreds of symbols during a
measurement run, in which T1.cont reliable collects the execution times. The
need for time-consuming, off-line instrumentation disappeared altogether. Thanks
to T1.test, the measurements themselves were fully automated.
Above all, the T1 support for multi-core was welcomed, since the number of
multi-core projects at Continental is steadily growing.
And, as a happy side-effect, Continental obtained a powerful tool for debugging
even awkward timing problems in the form of T1.scope.
Situation On rare occasions (6 times in one
year), the ECU software was observed to "freeze". Several tasks ceased
to run in the event. It seemed that the cause must be an operating
system defect. A group of experts investigated the problem at length and
with the assistance of static analysis tools, all without success.
Eventually they turned to the GLIWA timing experts, since they also have
extensive knowledge of operating systems.
Solution In the analysis of the limited
information collected so far about the defects, it transpired that they
always occurred after an exact multiple of about 17 minutes. The
GLIWA experts pursued this fact and quickly established that the system
tick duration multiplied by 2ˆ32 (the normal timing width) was
exactly the 17 minute interval. With detailed knowledge of the
processor, the conditions for the appearance of the defect were
accelerated from "once in 17 minutes" to "around 30 time a
second". Now the defect could be quickly and reliable reproduced in the
laboratory, localized and corrected. The failure to save and restore the
Condition Register when handling the Decrementer interrupt had been the
guilty party in the delivered code.
Situation The project in question included
measurement technology for reporting the net run-times of tasks and
interrupts and also the CPU load. Despite this, timing problems occurred
and it was decided to integrate T1 to pinpoint the cause.
Solution After the T1 adaptation and
integration, T1.scope displayed the scheduling behaviour of the real
system. It was immediately apparent that one of the interrupts occurred
far more frequently that expected. This situation could not have been
revealed by static scheduling analysis or simulation. The cause was
quickly located: an inaccurate configuration of the interrupt
source. After the correction, the CPU load dropped by around 10%.
Situation Back in 2003 GLIWA timing measurement
technology began in steering projects of Tier1_2. After
successful use in individual project came the requirement for a
comprehensive, "blanket" deployment.
Solution The T1 platform integration adds, to
the regular T1 integration, the knowledge transfer for the automatic
support of further projects. As this progresses, the customer develops
their own, in-house T1 experts, who can handle new ECU projects without
requiring engineering and coaching from GLIWA.
Situation For a new project, a brand new
processor was specified. For months, two OS suppliers had been trying to
port their product and integrate it into the steering
project. Unfortunately, they had not succeeded, and the development
schedule was coming under more and more pressure as time went on, since
the function development required a functioning platform for
development and verification.
Solution The GLIWA operating system experts were
brought in to assist. After quickly determining that the envisaged OS
was still not ready, gliwOS was rapidly ported to the new processor and
even integrated into the project on the same day.
The T1 interface is an easily activated standard component of gliwOS.
And so, by the evening of this remarkable day, the Tier1_3 engineers
not only had a running project but could also visualize, measure and