Design Phase Product Integration Management- A new GA Aircraft 6

I'm not aware of any formal systems. Obviously the largest a/c companies would have something, presumably proprietary. In my experience it has been a room full of presumably smart people. And most of the time that works. But one of my sayings at work is "every time someone new walks into the room, they ask a new question", one that hadn't been expressly considered.

My sense is it (a system as you posit) is "unicorn-ware" ... the interactions of everything are so deep and multi-faceted that trying to chase them all would be impossible ... a new system is going to new inter-connections and interactions, sometimes found during test, sometimes at the end of a "Mayday" episode.

Sure you could do a threat/victim matrix (similar to EMI/EMC) for Everything on the plane, but that'd be enormous, filled mostly with "N/A", and I'd bet you'd miss something !

1) the org needs experienced chief engineers who have been thru it multiple times, know what they are doing, know how to conduct effective design reviews, and know how to make decisions
2) need detailed, clear, robust ICDs for EVERY interface
3) checklists are just a tool, not a panacea; takes willingness and discipline to use them
4) hold multiple design reviews for each ICD
5) success will be inversely proportional to the number of MBAs involved in the program

It sounds to me like you're starting a design project (for a GA airplane) and starting at close to "ground zero".

There are many questions that need to be answered before your start worrying about the interactions between systems, which are I suggest well known for well known systems.

The first question must be what sort of plane ? how used ? what need is it filling ? why are you doing it ?
The next must be how are we going to certify ? Do you have delegates ? Will you hire them ?? (Be Very careful with this approach, and think long and hard about who you get onboard and know ahead of time the absolute sh1t show that results if you have to change them.
Which authority is certifying ? FAA, EASA, CAA, ... get a relationship going with them early ... it will pay dividends in the long run.
Then you can start worrying about the economics for the project, and the schedule.

Remember how to make a small fortune in aerospace ? (start with a large one)

Thank you for all these good answers. Please keep them rolling and let me give a little background below. I have been involved in PDR's since early 1990's on space and aircraft projects but I am still a bit baffled by the question below, even though I have just participated in a complete design review for a small jet recently.

The question comes from an Investors Tech rep, whom I think may be approaching the question of product liability & Certification risk via the design organisation manual and the boundaries between liability by a system supplier and the airframe developer. It kind of alludes to what systematic approach do you have to control interface issues. I

I am guessing that this question leads to the answer that will appear in the certification compliance documents. There are several levels in this ranging from the design methodology at the interface to the applicable standards at the interface. All the physical analysis will be done by experienced design teams. I don't know if there is a defining one stop method-standard which describes what you should do (universally) at the interfaces to ensure physical adequacy and compliance.

I think the outcome of the design review at interfaces might look like something the structure below.

The hierarchy might go something like this:.

Product Specification: FAR 23.
Type : Amphibian.
Class: Public Transport or Normal Utility.
Sub section: Wing
Interface: Aileron PCU.
ATA: Chapters X, Y, Z
Defined Interfaces: Structure: Moveables. Controls
Power Devices: Electrical, Hydraulic, Cable operated.
Structure Interface: Metallic to Composite.
Applicable FAR's.......List of paragraphs.
Design Compliance: BDM ABCDE, i.e. Static, FDT, Lug analysis, bolted moveable joints, etc
Applicable TSO, BDM, AC's, etc.
Other Applicable Standards: Wet Shimming i.a.w BDM XYZ., Bolt Torque per NAS XYZ, Bonding i.a.w etc.
Joint Types: FSJC: Apply Safety lock devices (split pins i.a.w. XYZ)
Application Standard Callouts: To be defined on interface drawings and DCN, etc.
Finished: Interface surfaces to roughness RA.
Materials: I.A.W accepted Galvanic standards.

Many of these are to the company's internal approved standards of course

I can recall one project in Europe for European Space Agency that had some mention of interface compliance structures and used an ISO standard and actually had a chapter on what to do on mechanical interfaces. In aircraft, EASA of course has volumes on Design Organisations Exposition manual nowadays. The problem is that the latest theme from EASA might be applicable only in Airbus but not in independent smaller companys. ARP 4754 was a large book used as a door stopper in one company, yet it is consistently mentioned as applicable for design reviews. It excludes airframe structure I believe. It is down to the design teams to vet the interfaces against all the knowledge they have picked up and review the advisory circulars and so on within the company system of documentation-at least these is how these reviews are conducted. One space project in the 90's, we used an IS0 method or design standard for interfaces- the practical implication was that the design analysis was done in the normal way then as PDR approached, we put a team together to write the interface documents which was sort of a quality assurance action. These document were intended to show compliance with the design exposition or DO's quality assurance. It was more like a 'one size' fits all compliance list. The document didnt unearth anything that was missed but more a less provided documentary evidence that the job was done to 'latest' ancient standards.

Your ideas and memories of experience will be much appreciated.

Casilero said:

The question comes from an Investors Tech rep,

Click to expand...

what exactly is the question? and is it from someone who has any remote clue about how aircraft are designed?

if the question is:

"what systematic approach do you have to control interface issues?"

then the answer is to hire competent, experienced engineers. no amount of checklists or standards or whatnot (or AI BS) will save you if the staff does not have the requisite experience.

I would add ... work with known systems, systems known to "play nicely together".

Further what sort of systems is the questioner questioning ? (I know he probably doesn't know.)
This is a simple enough plane (FAR23), and you're looking at specifically hydraulic controls ?
Ok, hydraulic systems are "nasty" as they all (all the systems sharing a hydraulic circuit) interact.
How is the interaction handled ? By careful design by knowing engineers, then proven by testing (Iron bird ideally, but maybe a FAR23 project doesn't stretch that far), and finally by flight test.

Let me go back to the question again: The customer wants help to ensure they manage the interfaces well in new aircraft (not just the wing) across all products attaching to the airframe. Its a bid proposal. The customer is not disclosing how they plan to manage the issue nor what project management system they follow. It is known that customer's last whole aircraft project was badly managed resulting in a very prolonged design & certification phase, partly its systems integration. Reading between the lines, it seems the question is more to do with 'how do we ensure we have smooth integration of components and assemblies onto the structure so as not to repeat the last fiasco'.

The question may have more to do with the smooth flow of design coordination and assurance and it may be impacted a lot by the procurement of equipment, how RFQ are developed, specification management, contract delivery milestones, etc. If this is the case, it can have more to do with the realism of design expectations, available state of the art, technological risk and how all that is handled in project control. Well its not a break the sound barrier job here. Its a composite airframe with standard engines and it is suited to particular niche market in the utility industry.


Read on if you are interested and any comments would be appreciated!

Examples that come to mind are: that the equipment supplier is not aware of the specific design needs or ignores them until it is late in the design cycle, or cannot deliver on time, supplier will not adjust their interface to meet the available interface, airframe developer does not insist on firm supplier equipment specification until late on, landing gear behaviour differs or is more complex than original elementary specification-creep of specification-revise the LDG, takes time, schedule blows. If there are two big areas where all this becomes a serious issue and that is Engine and LDG. Unexpected things happen but design assurance and several responders pointed out, means putting design management on the job not taking it out.

This mal coordination happens in the best of projects, the cabin team makes changes to the airframe which are approved by cabin but airframe team would not accept-not known till after the event. Same for Avionics, unauthorised changes perhaps not seen until they are a problem, airframe design team has already departed, so questions remain and become a cost for rectification and a delay. In another case, holes were drilled into the spar flanges for P clips to support a wiring loom across the full length of the wing, not ideal, its all about coordination. The loom was not in the DMU.

The traditional approach to airframe development is FAR's, Acceptable means of compliance, testing at material, part, sub assembly, assembly and full integration level, airframe structural tests and flight tests. we can see that rather nicely in the following AC for fuel systems. Note that it does not tell us to do structural test, or manage the interface question for us, let alone tell us what to do at the interface of say a fuel pump mounting in the tank. It could never all be specified in a cook book solution. https://www.faa.gov/documentLibrary/media/Advisory_Circular/AC_25.981-1C.pdf

It seems to me that there is design compliance, real design iterations including interface issues between airframe designers and sub system suppliers that just have to be worked out together, then other project consideration like future provision for events during service life, damage, fatigue inspections interval justifications, etc. These all affect the interface just as they do any piece of structure, but inexperienced project management often assume that integration of system to airframe does not require overlap between teams working together during the design phase, or that it is OK to leave it to last minute to integrate it all together or not even put design management on the interface design coordination. It happens on the biggest project that this is overlooked also.

'how do we ensure we have smooth integration of components and assemblies onto the structure so as not to repeat the last fiasco'.

learn from your experience. hire experienced designers. but I think the better lesson is "drop these guys like a lead ... whatever"

Sorry but your post seems very circular ... "The customer wants help to ensure they manage the interfaces well" ... "The customer is not disclosing how they plan to manage the issue" ... "airframe developer does not insist on firm supplier equipment specification until late on" (oh boy, what a red flag !) ... "Unexpected things happen but design assurance and several responders pointed out, means putting design management on the job not taking it out." (unexpected things Always happen, you don't react to them with project planning or mgmt s/ware; you react to them with action).

I go back to "drop these guys" 'cause I don't think they want to, or will, learn and change their behaviour.

But this is a FAR23 plane ... these are simple (well, simple compared to other classes) and solutions need to be cheap (otherwise the budget "blows out") ... but cheap does not mean "nasty".

If the point of this is "we want to develop our aerospace business", then learn from your experience ... designing a plane, even a FAR23 plane, is very difficult and needs a lot of experience. The previous story tells you "we don't have the experience necessary to understand how to package the plane's components", then grow that experience ... do some component assembly (make other people's bits) there is plenty to learn with that, then larger components, then finally undertake your own design project. Plan to invest a whole boat load (a boat the size of Titanic) of money to do this. This is a strategic multi-decadal project.

So your investor rep is asking how do you control the programmatic risk of design rework at interfaces.
There's no standard for that. Companies that have known this pain have gated review processes (in addition to PDR, CDR) to coordinate maturity across interfaces and also between disciplines (design, stress).

Casilero said:

The customer wants help to ensure they manage the interfaces well in new aircraft

Click to expand...

ok, who exactly is the customer? the aircraft OEM?
and who do you work for? the OEM? a supplier? some other company?

I agree with rb, "the customer" seems to be the problem.

@Casilero It will be quite useful to understand your role in the project and the role of "the customer".

It's beginning to sound like "the customer" is an aircraft manufacturer, and you are a consultant attempting to crowd source the knowledge that you presumably are being paid to already have.

ARP4754, ARP4761, AC 25.1309-1, DO-254, DO-178C, various publications from INCOSE, Nancy Leveson, OMG etc. define a collective "best practice", and every manufacturer and supplier knows how to write various "Design Management Plans", "Project Management Plans" and proposal slides proclaiming how they are used to avoid every possible problem and risk.

The trick is to actually hire and train the staff needed to implement it all, give them the right tools, and then actually do it. Nobody ever gets to that point.

Possibly related...

I have recently noticed... looking thru several +70-YO corporate libraries... that the most successful aero engineering projects had a common denominator.

Each had a master document... a 'design road map'... that broke the project complexity into major sections, sub-sections and sub-sub-sections... with experts contributing their knowledge, complexity, challenges and concerns. The title for most of these documents included one common phrase... DESIGN DATA BOOK.... and also referenced every other base/preliminary document for the project. Sections could be added IF/AS needed.

This included detailed layouts for every element and governing documents... sketches, mock-ups, materials, fastening, hardware, equipment, and so-on...

In a sense this document was in the hands of very designer and analyst... so that they were aware of everything that affected their element of the project.

DESIGN DATA BOOK <-- This!

Write down what you need to do and how you're going to do it.

Keep it up-to-date.

Make sure everyone on the project has access to it.

That's basically the left half of the "V Model" that's in every one of the standards I mentioned earlier.

yes ... information sharing ... everyone needs all the information (that they want). Unfortunately they often don't know what they need (even if it is available). It's easier (and harder) in these digital days ... easier to record data, easy to access it, but now there are such mountains of it that it is hard to find what you want.

the other absolutely key thing in a project is controlling the information. Design information is going to be constantly changing. each discipline will be working initially with assumptions (aero will have a weight assumption, particularly a structural weight; this will be refined as the design progresses). This can be neatly controlled by design reviews ... PDR, PDR.2 (etc), CDR, ... and analysis loops within these review cycles.

Look into an airplane design textbook ... Torenbeek or Raymer are good starting points.

But now we're talking about general design, rather than specifically interface controls. The whole point of design is how the initial guesswork and estimated (hoped for) plane gradually becomes a consistent fact (or beast). The problem with design is that you don't know if your design decisions were correct until many years into the future, which is why you want people who have been through the process, who have some idea of what the process is like, and who can "keep their head whilst all around people are losing theirs and blaming it on you". Making decisions is key ... not making decisions wastes time and money.

It sounds like someone has asked "how are we going to avoid the CF we had last time ?" and I suggest the most effective answer is "we're going with a different company, dropping those jokers". A nicer answer may be "we need to understand how these guys work, and how can we get them to change"

Please accept my thanks for your many interesting contributions. The question " we need a system or help to manage the interfaces" is perhaps a tell tale sign of one of two things or perhaps both. 1: The programme management system may need a review, 2 the engineering team may need support. 3. The project is already off track.

The first two of these issues are manageable with resources to some degree. Of course there are some projects where the team is out of its depth and the issues becomes recognising this, getting acceptance and finding solutions for this or not.

I can only speculate on how the third issue might manifest but from past experience it goes something like this-sort of risk management, early stage equipment supplier selection-partners effectively. Generally the airframe is under internal company control but the external subcontractors supplying equipment, may have to develop new equipment and this is where 'Interface control' may really bite because it not really about the coordination of the equipment placement, its about redesigning the interfaces after failed critical new equipment design as emergency fix to accommodate something else. Thinking of the humble example of a new flap drive gearbox and the seller promises and contracted to design a new box but actually internally, that subcontractor tries, failed and conceals it till last moment, despite critical risk reviews. Yet the airframer, cannot get sight into the working of the new product before it is too late. Delay, excuses, mis information are the norm. One can take the somewhat luxurious position of 'lets only use tried and tested equipment' or have a back up plan at the start-which is often very difficult for bespoke equipment or apply severe non deliverable penalties (not many subbies might be interested). It applies to many pieces of equipment. The gearbox is just one which rears its head quite often.

Thats is from me, many thanks for these contributions.

Ah so your critical risk reviews were just box ticking? That's the real issue - no procedure can enforce integrity.

GregLocock said:

no procedure can enforce integrity.

Click to expand...

True.

Yet, doing those risk and design review meetings at the vendors' facility, with the right people, asking hard questions, looking at the shop and understanding what the hear and see can absolutely detect a lack of integrity.

From there it's up to the project managers.

Personal anecdote:

During a review at the vendor's facility it was obvious to me that there was a lack of integrity and that the vendor would never deliver compliant, quality equipment.

I called the PM; "You need to disqualify this vendor because of A and B and C, and here are the contract requirements they are demonstrably violating."

"No, we'll just stay on top of them, watch them carefully".

Fast forward a few years, all of the vendor's material had to be removed from a fleet of about 1,000 train cars.

I don't I understand enough of the situation to say "you're already off the rails" but I think that you seem to not recognise the importance of defining key system requirements early and many of the other things that only came up in passing suggests to me that the cliff edge is not far away.

It sounds like you've some experience with the guys doing (or who would be doing the design) that it should be a reasonably easy call to say "these guys are a bunch of clowns" but your first thought is some project management s/ware.

Back to my previous suggestion ... drop these guys.