Thanks to T1, we can continue to use our ECU for the next generation. We are not talking about a small optimization, T1 saved us an entire development cycle!
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.
With T1 we were able to reduce the turn-around time for our automated measurements from around 6 hours to below 1.5 hours. And that applies generically to many projects. The time saving is enormous!
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.
Unbelievable: the sporadic crashes, which our specially assembled task force hunted for months, were resolved by the Gliwa experts in a few days. It saved our SOP [start of production date].
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.
When you first see the actual scheduling, many problems are solved in next to no time. Within a few hours of the T1 integration, we have detected and freed up 10% wasted CPU-Load!
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%.
For year T1 has been an essential component of the platform. New projects automatically provide timing verification via T1. Our customers are also very pleased with this timing verification. T1 makes static timing analysis techniques redundant.
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.
Within a single day the GLIWA experts ported and integrated a functioning beta version of gliwOS. By the second day we were able to resume function development and verification and to deliver on time.
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 engineers not only had a running project but could also visualize, measure and debug it with T1.