boacvc10 From United States of America, joined Jul 2006, 628 posts, RR: 0 Posted (3 years 3 months 1 week 4 days ago) and read 7010 times:
Hi, just curious to know if there were any publications that analyzed reasons why the CATIA V4/V5 issue was not detected early in the A380 development program, and allowed to progress until it was discovered that the (siginfiicant) component designs did not/could not be matched up between Airbus factories.
It might have been covered elsewhere than a.net, and I would appreciate any links. Were no software translation tools developed to automate the homogenization of the two work flows? How and when were the issues resolved?
I'm asking because: I'm involved in a small way in developing systems for academic nanosatellites, that will be integrated into other spacecraft bus ... it's very likely that what I write in the next few years will be utilized in real systems several generations later - and I won't know how/where/when as I will be long gone from my university What design lessons can we learn from this past aerospace industry debacle ?
Every Catia-savy engineer I know has spoken ill of the V4 to V5 transition - it affected many more than just Airbus.
V5 was completely, totally different, the interface was totally alien in comparison to V4, and the models produced in one weren't completely transferable to the other without some loss of fidelity. I think Dassault was trying to compete with other up-and-coming CAD packages when they created V5 and basically tried to duplicate them.
When Dassault did this they were not interested in supporting V4 any longer or making V5 particularly backward compatible and thus basically held any V4 operators to ransom, forcing them to upgrade and retrain their engineers or risk falling behind their competitors, also V5 was actually launched right after Dassault acquired Solidworks so that probably had an influence, even though IMHO solidworks is still easier to use.
Back when I was using V4 I loved working with it(though many others did not), to me it seemed highly customizable and logical, the only problem was it lacked processing power - even with a tower the size of a broom closet manipulating any sort of complex component was extremely time consuming. When Dassault launched V5 it was much faster and more powerful, particularly in kinematics, but I felt they dumped a lot of useful features from V4 which they apparently deemed un-necessary.
The final straw is the VPM/Enovia transition, which also completely changed from V4 to V5, forcing engineers to unlearn everything about the one software and re-learn the new.
In summary, regarding harmonizing workflows, at the beginning of any digitally based design project between two or more parties, there has to be concurrence on the software to be used and the format for submittal of models etc etc for the duration of the program, changing CAD packages halfway through a program, as was the case on A380, does not help, although I can't speculate if this was something they had to do because the plane was too big and complex to manage in V4?
Otherwise I think if you want to upgrade your CAD/VPM software - be sure to save it for the next airplane, don't change your mind halfway through.
Roseflyer From United States of America, joined Feb 2004, 10485 posts, RR: 52
Reply 2, posted (3 years 3 months 1 week 1 day 7 hours ago) and read 6436 times:
Quoting boacvc10 (Thread starter): Were no software translation tools developed to automate the homogenization of the two work flows? How and when were the issues resolved?
V4-V5 conversion is a mess. The two systems are very different. There is conversion, but when you pull a part from V4 to V5, it does not come across smoothly. The part is not the same as if it was created originally in V5. It gets difficult to explain, but what makes things worse is that there is no effective tool that I have seen from Dassault that effectively takes a part from V5 and converts to V4. I can understand why Dassault does not want to create such a tool, but it makes special integration very difficult in V4. It might exist, but I haven’t seen it and it can cause parts not to match up.
The part definition between the two is different. So while you can route a wire bundle in V4 and you can route a wire bundle in V5, neither ends up exactly like the final product. Airbus had the extra complication, of trying to match V4, V5, and reality. In routing wire bundles, hydraulic tubes, etc through structure, you have a huge mass of tolerances. Structural tolerances can get quite flexible and then you have electrical and hydraulic tolerances. When you add poor part definition, and overly customized routings, you end up with a product that is not manufacturable.
One problem I have seen is a lot of people that are not specifically mechanical engineers don’t understand tolerances. Wire bundles are often routed by electrical engineers. Decisions are made by business minded people and software is designed by software engineers and computer scientists. Tolerance stackups create big problems and have to be designed for. It is very easy to design for a 20 inch wire bundle that has a 2 inch bend radius. What is not easier to design for is a 20 +/- 0.1 inch wire bundle with a bend radius of 2 +/- 0.5 inches being mounted to structure that has a 0.2 inch tolerance supported by brackets with a 0.05 inch tolerance through holes that have a location tolerance of 0.08 inches. When all of that stacks up, sometimes things don’t fit and you end up with cascading interferences and piles of rework.
Quoting boacvc10 (Thread starter): Hi, just curious to know if there were any publications that analyzed reasons why the CATIA V4/V5 issue was not detected early in the A380 development program, and allowed to progress until it was discovered that the (siginfiicant) component designs did not/could not be matched up between Airbus factories.
They knew it would be a problem from the start. How they managed it was a bigger problem. Boeing had the same problems with the 747-8 since the existing 747-400 was a mix of V4 and mylar drawings. Some 747-8 was V4 and some was V5. Lockheed Martin has seen the same problems as well.
As a new user to V5, I find it far easier to use. I also think of it similar to other CAD programs, which V4 is a very different platform. I found it easier going from Unigraphix and Solidworks to V5 than trying to go from V4 to V5 from a design standpoint. Dassault benchmarked the competitors programs and did not start with their own software philosophy.
If you have never designed an airplane part before, let the real designers do the work!
bikerthai From United States of America, joined Apr 2010, 2343 posts, RR: 4
Reply 3, posted (3 years 3 months 1 week 1 day 6 hours ago) and read 6420 times:
Haven't read much about what happened to the A380 wiring gaffe, but the V4/V5 conversion issue may have been simplified.
In my current program we had to work both in V4 and V5. This is because when we began, V5 was great for building parts but was not robust enough to do wiring. Our wiring counterpart continued with V4 until recently when they feel that the V5 package was able to support there operation. This was possible because we had a different software that does the integration (visualization etc . . . ). Given the complexity of a large airplane and the relative lower computing capability of desk-top computers at the time, doing integration using V5 software alone would have been very difficult.
I'm sure Airbus have their own integration system to do this. I would think any break down of integration would be blamed on the integration system and not on V4 or V5. Unless you are using one or the other as an integration tool. In that case, you are just looking for trouble.
ferpe From France, joined Nov 2010, 2805 posts, RR: 60
Reply 5, posted (3 years 3 months 1 week 4 hours ago) and read 6073 times:
When researching the Airbus PLM solution (based on PTC Windchill) some time ago I came a across as very competent article describing the V4/V5 problem in some detail, unfortunately the article is in German:
In essence it was not a V4/V5 problem only, the historical CAD tool for Aibus was ComputerVision CADDS, the PLM was PTC Windchill in Airbus version called PRIMES. Airbus had decided to migrate to CATIA5 and PRIMES but this link did not work yet so German Airbus decided to introduce CATIA4 and ENOVIA while other parts was on CATIA5 and still others on CADDS5. Given the decision to only have a digital aircraft model and not full size mock-up one of the the challenges was to create a common digital model out of these 3 modelers. There was a specialist company contracted to do this (PROSTEP). The ran the conversion once a week or sometimes over night but as described by previous posts it was not easy, the many formats did not make things easier, in short is was a mess.
Out of this came a big project to unify everything which went to standardize on CATIA5 and Windchill (now called PHENIX)
IMO those 6 words provide the most excellent and to-the-point summary !
Because I think the organization mess was precisely the point ; the CATIA versions issue was only a consequence of this mess, but as it is the most illustrative and easy to understand, it is the best known problem.
The main thing to remember is that the Airbus building the A380 was fundamentally different to the Airbus that starting designing it. Since 2001, Airbus is a single company, and that's how we all see it. But before 2001, "Airbus" was a loose association of several state-sponsored national aerospace champions, each working for their own interests within the frame of a French legal entity called "Groupement d'Interet Economique". http://en.wikipedia.org/wiki/Groupem...7int%C3%A9r%C3%AAt_%C3%A9conomique
Each of these separate companies forming Airbus had their own processes and tools : requirements tools, design tools, simulation tools, testing tools, IT equipment (simple example : for the OS, use Windows or Linux ?), etc...
For wirings, I'm guessing you would need a tool chain looking like :
- tool(s) for requirement (like DOORS)
- tool(s) to functionally design the equipment (like the old SAO, or now SCADE, used to design Airbus flight control systems)
- tool(s) to physically design the equipment (that would be CATIA or similar)
- tool(s) to functionally design the wiring between said-equipment, and all the associated connectors, relays etc...
- tool(s) to physically design the wiring
- tool(s) to test the designs
- tool(s) to test the produced harness
- tool(s) to test the entire system equipment + wiring
- tool(s) to manage the configuration of all components
- tool(s) to manage change requests from all the stakeholders
- tool(s) for PLM to oversee all of the above
and that's just the parts I can think of off the top of my head. You always have several choices for each tool, so each company would have its own tool chains and usage practices to suit it's own needs and interests. And the resulting processes & tool chains are not things you can change overnight. Especially if there are also national & cultural aspects involved, as there were (and are) here.
You could easily imagine that if you have no unified management of all those tools, there is a good chance there is going to be a screw up. Especially if the end-product is a highly integrated system, which is the case of airliners, and even more so of the recent designs like the A380, 787 and A350. Any little problem in one part of the design can rapidly propagate to huge proportions through the entire design.
The Airbus GIE had done very well back in the 80s when designing the A320 & A330/A340, as these aircraft have less tightly integrated systems and were designed with more "manual" methods. The A380 was for Airbus the first design of the computer age, with much more coupling between systems, and many more computer tools to assist the development.
And as the A380 design work was being done, Airbus was trying to integrate itself as a company and had little or no unified tool management. This means either making sure everyone uses the same tool (easier said than done), or more simply "let's keep track of who is using what, analyze what problems may appear and find ways to solve those problems". Which in turn means that everyone has to be talking with everyone else to see what is happening in other parts of the company.
=> Keywords : proper communication
Ferpe's post indicates that some measures were in place, but I suspect they were far from sufficient and only worked for a time thanks to "inertia" carried over from the previous organization. That is for the technical aspect, but the same holds for the management structure as well, as the Airbus/EADS organization also "exploded" around the same time the technical problems surfaced (2005-2007). The structure in place was very inefficient, but worked well enough until actual major decisions had to be made, and everyone realized what a mess it was.
All that being said, integrating such a huge company from 4 different national champions is no easy task, and my experience shows that there is still much to be done...
But the fundamental idea is : if you work in a team, make sure you're talking with the other guys, make sure you know what they're doing and make sure they know what you are doing (that's the hard part, because it is easy to overlook).
And that is especially true for teams dispersed in different locations, or dispersed in time (if, as in the OP's case, someone might have to take over in 20 years. I worked on a few flight simulators made before I was even born, and would have appreciated a few comments in the code to explain what the designers had done )
Note that this is all based on my own experience, observations and feelings, and is my opinion only !
I did get a little carried away into a loooong post, but as I said, it's all summed up by