CRJ1000 prototypes proving software fix
Bombardier hopes it has seen the last of the software “glitches” that began plaguing the CRJ1000 control-by-wire rudder system early last summer, resulting in the grounding of the pair of prototypes used for flight testing and a certification delay of at least a year.
Flight testing of Bombardier’s new CRJ1000 resumed on February 13, when S/N 19991 took to the air from the company’s Wichita flight-test center, some five months after a second software malfunction prompted the company to completely halt flight testing. In fact, the grounding appeared to have lasted six weeks longer than originally anticipated, judging by the somewhat vague target to resume flying set by Bombardier Aerospace president and COO Guy Hachey during the company’s third-quarter earnings call early last December. At the time, Hachey had said that the company planned to start flying its pair of CRJ1000 test articles “shortly after Christmas.”
Bombardier vice president of commercial aircraft programs Ben Boehm told AIN in late February that there remained between 200 and 300 hours of total flying to do before the program finishes certification trials. “[The airplanes] will obviously still do a little bit of work at Wichita,” said Boehm. “We’ll continue with a little bit of work on field performance down in Roswell, [N.M.].” Following the Roswell tests, Bombardier planned to perform hot-weather testing in the southern U.S., most likely in Yuma or Phoenix, said Boehm, then do cold-soak testing in Alberta or Manitoba, Canada. “This stuff tracks the weather, and thanks to it being winter, we don’t need to go that far north [for cold-weather testing],” said Boehm, who declined to issue any time estimates for the various milestones.
Although by the start of last month the program still needed to complete roughly 30 percent of its testing regime, the additional delay did not force Bombardier to shift the rather generous half-year time frame it allowed itself for certification. Because Bombardier’s fiscal year ends January 31, its second-half target gives it until early next year to certify the airplane and deliver the first example to one of two possible launch customers–France’s Brit Air or Spain’s Air Nostrum.
“We’re talking with both of them,” said Boehm. “And I’d rather not say [which will take the first airplane] until both of them are satisfied with what we’re doing.” Boehm also hedged somewhat on the question of late-delivery penalties. “We’ve been in relatively constant communication with both carriers; both carriers are satisfied with what our situation is and where we’re going,” he said. “I mean, they’re not happy with the delay, but they are understanding and we’re all on good terms.”
The original software problem, first revealed early last summer, initially delayed planned certification from late last year to this year’s first fiscal quarter. “At the time we thought we had found the root cause, we did put some fixes in place, and we experienced another one almost a month- and-a-half later [at the end of August] similar to the one we had earlier,” said Hachey in December.
“Obviously we did not get the root cause [at that time],” he added. “At that point we put together our most seasoned people outside the program for external help to make a full assessment of the problem, and we have determined the root cause.”
Boehm, however, noted that although all the ground simulation appeared to have validated the software fix, only flight trials could confirm that engineers had permanently solved the problem. “Right now we want to focus on the robustness of the software, make sure we truly have captured what we think the problems were, then we’re going to refocus back on the flight testing and get our schedule on track and get our customers the airplanes they want,” said Boehm.
Until that time, Bombardier wouldn’t even know whether or not the two software glitches emanated from the same source. “You know, in flight testing, it’s hard to say, ‘Were they the same source?’” said Boehm. “I’d rather simply just say that it was related [to] the software, and by the second time we realized that this was something that we need to [resolve]…you know, we want to make sure that we’re building a great product, a reliable product, a safe product, and from that standpoint that’s where we take that step back and realize the software needs some work.”