MENU
Kazubara
Site administrator
A former engine designer at an automobile manufacturer. I will share my mechanical design skills based on 15 years of work experience. For job inquiries, please contact me using the inquiry button below.

Technological History and Lessons Learned from the Comet Crash, Part 14: Challenging Unknown Territories (High Altitude, High-Speed ​​Flight) (Systems Engineering, Agile, Waterfall, Requirements Definition, RFP)

In the previous installments, we discussed the general engineering lessons learned from the Comet jet crash and considered what further lessons can be learned.

In the previous re-examination of the causes, we discussed the multi-perspective checks and mutual checks conducted by surrounding stakeholders, organizations, and Comet.

From here, let's consider what problems were encountered during the development and manufacturing of the Comet.

To deepen our understanding, let's first look at an example of how to tackle uncharted territory in the modern age.

I believe similar considerations were likely made during the development of the Comet, which involves high-altitude, high-speed flight—a field probably considered uncharted territory—so I would definitely like you to take a look at it.

At the end of the last post, I mentioned that when venturing into uncharted territory, the key to success lies in how to concretize the unknown. So this time, I'll explain how to actually do that.

table of contents

The concretization of unknown territory

First, to make things concrete, we simply list all the phenomena that will occur in the machines and products we are going to develop.

In the case of the Comet, it's easy to focus on the new mechanism and machine of the jet engine, but we must resist that urge and instead consider and list the events that could occur from the aircraft's concept.

For example, let's list a few things that are unknown phenomena.

Examples of extracting unknown phenomena

- It cruises at a higher speed than existing passenger aircraft.

- It flies at a much higher altitude than existing passenger aircraft.

Unlike military aircraft with similar performance, it flies at high altitudes, high speeds, and for long periods of time and distance.

Unlike military aircraft with similar performance, the aircraft has a longer required lifespan.

Unlike military aircraft with similar performance, it has a higher number of takeoffs and landings.

Unlike military aircraft with similar performance, it has a large passenger capacity.

By comparing it to existing things, we gradually make the unknown phenomena more concrete.

The ideal way is,By gathering people from various fields, including not only engineers but also natural scientists and humanities specialists, and listing the phenomena, we can reduce omissions and more comprehensively cover all possible occurrences.

At this stage, it's important to accept even somewhat abstract ideas and gather as many thoughts and concepts as possible.

Simply put, it's about imagining what would happen if a comet were to fly and listing all the ideas that come to mind.

this is,This is a very important point to consider, and any omissions or oversights here will cause serious problems later on.

If you don't know what kind of events will occur, you have two options: either conduct research to find out, or give up.

Engineering significance of occurrences

Next, we translate the specific phenomena we've identified into what they mean from an engineering perspective.

Engineering interpretation of extracted phenomena

- Cruising at high speed → Greater thrust places a higher load on the aircraft.

- Flying at high altitudes exposes the aircraft to cold, low-pressure environments.

- Flying for long periods of time and distance → Speed ​​and environmental stresses occur over a long period of time.

- Long lifespan → High fatigue strength required.

- A high number of takeoffs and landings means a high number of repeated load changes.

- A large number of passengers means the aircraft becomes larger, placing a greater load on the aircraft.

From this partMechanical engineering experts, electrical engineering experts, materials science experts, and others take the lead in relentlessly translating concepts into engineering meanings (definitions).

The key points here are:It is important to use existing academic and engineering terminology and formulas as much as possible to describe phenomena.

To put it in slightly more technical terms...We'll consider the necessary functions for Comet.

Naturally, here tooWhen it is not possible to assign an engineering meaning to a possible event, basic research becomes necessary.

Just like the previous situation, I'm faced with two choices here: either continue with basic research or quit.

Quantification in an engineering sense

Once this conversion is complete, the next step is to consider the degree of each engineering phenomenon that occurs and quantify it.

数値化

- High thrust results in a high load → A load of XX[kW] thrust and XX[N] is applied, and resistance of XXX[km/h] is applied to the aircraft.

- Low temperature, low pressure environment → an environment with a temperature of XX [°C] and a pressure of XX [atm].

- The load occurs for a long period of time → The load will be applied for XX hours.

- Long lifespan → Must withstand a required lifespan of XXXXXX hours and XXXXX uses.

- Frequent repeated loads → Applied to XXXXX cycles of repeated loads.

- Increased load due to larger aircraft → A load of XXXX kg and resistance equivalent to $XXXX m^3$ are applied.

By making things more and more specific in this way, you can figure out what kind of machine you'll need.

To put it in slightly more technical terms, here we determine the necessary performance for each of the required functions identified above.

If hereIf there are phenomena that cannot be quantified (measured as performance), we conclude that we still lack the fundamental technology to conquer that area.

In other words, it comes down to two choices: either continue with basic research or quit.

Examples of basic technologies includeThe most representative example of something that cannot be measured is the lack of established measurement methods; engineering is completely powerless to address phenomena that cannot be measured.

For example, The Apollo program's mission to the moon became possible because we were able to accurately measure the distance from Earth to the Moon and the environment of space.

It's like deciding on a destination, but not knowing the distance or the environment; then you have no idea how to get there.

That's why the U.S. is sending so many unmanned probes to Mars, Jupiter, and other parts of space – to measure the environment and collect data to use for future profits and advancements in engineering.

Of course, part of this is done purely out of scientific curiosity, but the world isn't that kind; it's a constant race to keep beating rivals in the future based on long-term strategies (the data that is made public is known, and the truly important data is confidential).

Next, we'll proceed with the design according to those conditions and then plan the verification tests.

The design process begins by considering existing mechanisms and components that can meet the given requirements.

Depending on the conditions, existing solutions may not suffice, in which case we either have to research suitable mechanisms or components, or abandon the project altogether.

On the other hand, those responsible for testing first consider what conditions can be confirmed using existing tests.

Depending on the conditions, some things may not be verifiable, so we need to devise tests that can verify them.

If there are no existing test facilities or measurement methods that meet the requirements, then we will either have to build the equipment, research measurement methods, or abandon the project altogether.

Taking the Comet's pressurized cabin as an example, the design process proceeds with conditions such as its size being large enough for 50 crew members, the load being XX [atm], and its lifespan being XXXXX [hours].

On the other hand, the testers consider things like recreating high-altitude environments (temperature XX°C, atmospheric pressure XX [atm]), methods for applying loads (compressed air, water), and test equipment (a swimming pool, etc.).

These conditionsDesign requirements and test requirements are compiled together and called a specification document (Spec).

This is how it's done.Requirements definition is sometimes called development or requirements development.

It's one of the development methodologies that's become popular recently (like agile development or waterfall development).

The basic rules for this approach are established in fields like systems engineering.

This area is extremely useful not only for mechanical design but also for creating anything (organizations, systems, programs, etc.), so I will explain it in much more detail later.

The analysis up to this point clarifies which areas require new investment (research into mechanisms, components, measurement methods, and test equipment preparation) and which can be handled with existing resources. A management decision is then made by weighing these against the potential profits and reputation (benefits) to be gained.

In other words, For engineers, analytical and observational skills are extremely important, in addition to academic knowledge and design skills.

またI think you could say that the profession of an engineer is like that of a translator, converting what people want to achieve into concrete engineering meanings (functions and performance).

No matter how renowned or academically brilliant an engineer may be, they will inevitably overlook or miss things.

Up to this point, the important thing is how to view things from many different perspectives and viewpoints.

In summary, the standard approach to venturing into uncharted territory is

STEP
Let's consider the possible events that could occur.

STEP
Determine the necessary functions based on the events that may occur.

STEP
Determine the required performance values ​​based on the necessary functions.

STEP
The design and test procedures are determined based on the required functions and performance values.

become.

Documents compiled in this mannerIt is called a requirements definition document, or RFP (Request For Proposal) in English.

This development method has been applied to older aircraft such as the F-15 and F-16, which you are all familiar with, and more recently to the F-22 and F-35.

If you're interested, you can search for RFP F-15, RFP A-10, etc., and you'll find the requirements specifications from NASA and JPL (Jet Propulsion Laboratory) in the United States.

It's only available in English, so it might be a little difficult to decipher, but I think it's quite interesting once you read it.

As I will explain in more detail later, a major reason why the F-35 fighter jet struggled to become a Joint Strike Fighter recently was that the Request for Proposal (RFP) was unprecedentedly large in volume.

In other words, the required performance figures became enormous because they integrated the roles of fighter jets, attack aircraft, and light bombers, in addition to those of the Air Force, Navy, and Marine Corps.

Furthermore, even within the same country, the operational systems and weapon systems differ between the Air Force, Navy, and Marine Corps, making the situation even more complex.

In other words, For the F-35, the uncharted territory was the integration of all organizations and missions into a single aircraft (using existing technologies).

To solve this problem, the United States trained and employed many specialists in systems engineering, who organized the necessary functions and performance derived from the requirements.

Actually, there are still job openings for systems engineers related to the F-35.

Engineering ethics when venturing into the unknown

Failure to properly analyze uncharted territory can lead to flawed management decisions, and in the worst-case scenario, the company could collapse.

Well, if the company just goes bankrupt, it's your own responsibility, but depending on the machinery and conditions,In the worst-case scenario, an accident can result in the loss of irreparable human lives.

This is a very serious matter, so let's approach it with the utmost care to avoid causing any harm to anyone, no matter how small.

This isThis has significant implications for engineering ethics.

The worst specific example I have witnessed is when pride, honor, or ambition clouds one's judgment, and even though one should know what might happen or what is impossible, they proceed by saying, "We can do it, there's no problem" (which is almost like cheating).

Because of this, problems frequently occur during development, causing a great deal of trouble for the people, organizations, and companies around them.

That level of issue might be forgivable, but even worse is when immature products are released onto the market, causing inconvenience to customers.

SoWhen exploring such uncharted territory, it's crucial to set aside worldly desires and approach it with an honest eye; otherwise, serious problems will arise later.

This approach, which starts from the product concept, is a top-down way of thinking.

Conversely, a bottom-up approach involves discovering a new phenomenon, finding a measurement method, or developing a mechanism through research, and then moving up to a concept to consider what kind of product can be created.

In any case, the final overall result will be the same for both.

It's just a matter of different approaches.

In my experience, the former viewpoint is more common in Europe and America, while the latter viewpoint is more common in Japan.

Furthermore, Japan is extremely poor at considering and deciding on the former concept.

Recently, perhaps due to the ease of making business decisions, the approach of starting with a concept has become popular, which is causing Japan's competitiveness to weaken relatively, and I am very worried about this.

A striking example of this can be seen in recent national strategies such as "electrification, carbon zero" and "COVID-19 countermeasures."

Both approaches are typical top-down models, where a concept is established and then implemented in a concrete way.

As explained, the top-down approach involves gradually concretizing the concept, and finally specifying the design conditions and the details of the measures taken.

However, in Japan, even though the concept is decided, there is little information available about "what phenomena will occur, their engineering significance, and how to quantify them," and then they suddenly implement the final design condition of electrifying automobiles or specific measures such as the COVID-19 self-isolation request, which makes it difficult to accept (it's done without much thought).

Japanese governments and companies, in particular, are not very good at creating Requests for Proposals (RFPs) as described above.

This top-down development method is being actively pursued in Japan by organizations such as JAXA (Japan Aerospace Exploration Agency), IPA (Information-technology Promotion Agency), and Keio University, but it hasn't spread widely.

The reason why the government is often criticized for "insufficient explanation" regarding its COVID-19 response is because the process of considering the relationship between the concept and the specific measures is kept a black box and invisible to the public.

It would be fine if it were simply a matter of not wanting to talk about it and keeping it a black box (though that's probably not good), but it would be problematic if they actually didn't consider it at all and just implemented the measure on a whim.

I hope I'm just worrying too much...

These are the main ways of thinking when venturing into uncharted territory, regardless of time or place, from the past to the present.

It's difficult to venture into uncharted territory without a clear understanding of the concepts up to this point.

The author believes that the true lesson of the Comet plane crash lies in how we approach venturing into this unknown territory.

In other words, It appears that there were significant problems not only with the engineering aspects but also with the conceptualization and development system.

Based on this, in the next installment we will follow the events of Comet in chronological order.

To those who found this article helpful in understanding design:

Since we're on the subject, I'd like to recommend a book that's essential for mechanical design.

To be honest, the content is extremely unhelpful, but it can be used like a dictionary when you forget the details. If you read this article, you should be able to understand the content and use it effectively. It also includes commonly used standards, making it quite useful.

If you don't already own one, I highly recommend getting one, even though it's a bit pricey. However, new ones are expensive, so if you're considering buying a used one, I strongly recommend checking that the surface roughness conforms to the new JIS standard.

[For those considering using our services in organizations such as corporations, companies, government agencies, and educational institutions.]
If you intend to use the information explained in this article for training, materials, technical standards development, or reports within your organization,Information page for corporations and organizationsPlease check the terms of use for more details.

We also offer consultations regarding detailed technical support and consulting.Dedicated formWe are accepting at.

No prior notification or special procedures are required for sharing on personal blogs or social media, or for using the content within the scope of appropriate citation (such as including the source). Please feel free to use it actively.

If you like this article
Follow me!

Share it if you like!
  • I copied the URL!
  • I copied the URL!

Person who wrote this article

Kazubara's avatar Kazubara Site administrator / Technical advisor / Article supervisor

Previously worked at Honda R&D (motorcycles), where I was responsible for engine and drivetrain design, CAE analysis, and systems engineering (design process construction using MBSE).
We promote the design and CAE of the CRF series and large motorcycles, as well as the development of design processes and field implementation projects.
I currently work as a website administrator, technical advisor, and article supervisor, so please feel free to contact me.
I also run a YouTube channel called "KazubaraTube," so please check it out.

Comment:

To comment

table of contents