Boeing postpones test flights again: How’s your tapeout looking?
Boeing's recent issues offer a cautionary tale for any chip-design team engaged in a complex project.
By Ron Wilson, Executive Editor -- EDN, November 12, 2009
Boeing—giant aircraft manufacturer, equally giant but much-lower-profile defense contractor, and one-time paragon of complex project management—has hit the newspapers twice in recent weeks in the worst possible way. The company has announced that it is taking financial charges because neither of its two premier commercial projects—the 787 Dreamliner and the 747-8 cargo version—will meet its most recent schedule for a first test flight. This concern directly affects suppliers providing electronics to those programs. But it is also a cautionary tale for any chip-design team engaged in a complex project.
The irony is that this scenario should happen to Boeing. In the late 1960s, Boeing astonished the aircraft industry by creating the most complex jetliner to date—the initial 747—on a tight schedule and at enormous risk. The company bet essentially its net worth on the 747 project—on a schedule so tight that the first planes for delivery were on the running production line right behind the plane for flight testing and FAA (Federal Aviation Administration) certification. If something had gone seriously wrong, Boeing might have had to rework a year’s worth of deliveries in parallel on the factory floor. But the plan—and the plane—worked. The 747 project became a case study in project management and forever altered the landscape of the commercial-aviation market.
That scenario happened when there was limited use of computers and engineers learned manual project-management skills over decades in the must-do environments of World War II, the Cold War, and the Apollo program. Boeing’s current disaster is taking place in an environment in which computers control everything. The managers supervising these projects typically have proven expertise in getting a master’s degree in business administration, not in getting a project out the door. And this era is one of outsourcing.
According to published reports, these changes lie at the heart of Boeing’s problems. To paraphrase one report, the 787 is an entirely modularized design, and Boeing outsourced the modules. The company intended that final assembly would comprise simply snapping together functionally complete modules, carrying the necessary electronic subsystems, cabling, plumbing, and mechanicals. When the modules started arriving, however, Boeing found that it had somehow lost control of the module designs. In some cases, things didn’t fit. In others, module designs exceeded the capabilities of the subcontractors, and so the modules arrived with subsystems missing. Modules required further assembly after delivery. Perhaps more disturbing, no one had, at a full-system level, reality-tested software simulations of the system-level mechanical behavior of the composite materials of which the modules were constructed.
By now, I’m sure this scenario is beginning to sound relevant to chip-design managers. We, too, live in a world of pervasive outsourcing, increasing dependence on simulation at several unlinked levels of abstraction, and no chance of a reality check until someone assembles the complete system. We, too, live in the shadow of the possibility that a system-level design error will become visible only when we flatten the design for physical extraction and DRC (design-rule checking) or during silicon debugging.
In some ways, our problem is more controllable. There are fewer degrees of freedom in even a challenging mixed-signal block than in a physical chunk of a jumbo jet. We have put a lot of investment into tools to manage those degrees of freedom we must accept. And unlike Boeing, no chip-design team is the only one doing what it is doing. (Intel’s R&D people are welcome to dispute this point.) So there is a body of experience, however imperfectly we share it.
Yet the caution is still there. It takes only a bit too much confidence in the tools and abstractions; just a little too much casual dealing with the company, language, and time barriers between the core team and the subcontractors; and one step too far down the path of partitioning to turn a challenging project into a catastrophe. The realities of mechanical design and the needs of Boeing’s customers place limitations on that company’s ambitions. But unlike Boeing, IC-design engineers are all servants of never-ceasing Moore’s Law. To paraphrase Intel, only the paranoid are likely to survive.
Contact me at ronald.wilson@reedbusiness.com.
