View Single Post
  #11  
Old November 6th 07, 11:22 PM posted to rec.aviation.piloting
[email protected]
external usenet poster
 
Posts: 684
Default Boeing admits 787 strategy flawed

On Nov 6, 11:16 am, Paul kgyy wrote:
There's also the possibility that Boeing simply overlooked the fact
that companies always have "standard" ways of doing certain things,
and neglected to be sufficiently detailed in their specifications.


No, here's just one example of what happened:

On the 777, the AIMS (Airplane Information Management System)
architecture and processing requirements were defined 100% by
engineers at Boeing (many are friends of mine). Honeywell, who did
the AIMS system, knew what the total MIPS requirements were for the
total processing taskload right at the start because Boeing engineers
were able to leverage past metrics and did a good job of projecting
the requirements for the new software and put it in the system
specifications. After all, they were the ones defining what all the
software tasks were, and could see the big picture and manage it.

For the 787, Smiths was given the task of writing the specifications
for the processor and doing the design of the core processor module
for the main avionics sytem, and other vendors (Honeywell, Collins,
etc.) wrote code to do their software functions that execute on the
Smiths hardware. Boeing didn't own the requirments for this
processing taskload, and allowed Smiths to own it. Smiths way
underestimated the total software taskload (didn't play well with
others, and vice versa), and underdesigned the CPM. Now, they are
having to put in twice the number of processor modules to handle the
taskload, which is doubling the power, doubling the weight, and eating
up all the planned growth margin for the system in the intitial
delivery configuration.

Like I said before, its all about doing a good job of top-level
requirements, integration, and vendor management, and Boeing has
traditionally done a world-class job of it, but on this airplane,
management thought that they could push more of this task on the
vendors with unfortunate results. IMHO its best for the system
integrator to own the system requirements, system design, system
integration, and vendor coordination tasks. Trusting this to the
vendors who are inherently in competition with each other is not the
wisest decision to make. The vendors' strength has always been the
detailed implementation of the requirements in hardware and software.