Helicopter Mid-Air Collision (Watch), Engine for MBSE & more …

Authored by John Fitch (PPI Course Presenter and Principal Consultant)

In the experience of this author, most systems engineering practitioners are familiar with Model-Based Systems Engineering (MBSE) in some form.? Many practitioners have learned SysML or another modeling language and have experience in populating a few of the standard diagrams from within a commercial MBSE tool. However, few practitioners have had the time or inclination to think deeply about the common principles that “power” the prevailing modeling languages and tools.? Fewer still have struggled through the process of:

• Defining, extending, or refining information metamodels (entity classes, attributes, and relationships).
• Updating engineering methods to support the capture of such structured knowledge.
• Mapping free-form paragraph text within source documents to a structured information metamodel, i.e., turning paragraph blobs into traceable objects/entities.
• Creating viewpoints (new diagram types) to visualize structured engineering knowledge.
• Developing software tools that guide the capture and use of structured engineering knowledge.
• Figuring out how to use software tools to detect inconsistencies in system models and to guide and confirm the resolution of such issues.
• Struggling to simplify the inherent complexity of modeling a system and the full range of thinking that creates that system.
• Completing cycles of learning from missteps and failures in all the efforts noted above.
• Detecting patterns of thought that are the common building blocks of successful MBSE practice.

This brief paper is an attempt to share one such pattern of thought that, in the opinion of the author, cuts across nearly all the tasks that we perform when engineering solutions to any problem. That pattern is MECE+ Thinking.

Origin and Use of MECE Pattern

The first use of the term MECE (Mutually Exclusive, Collectively Exhaustive) is attributed to Barbara Minto of the McKinsey consulting firm as part of a “Pyramid Tool” approach to aid the firm’s consultants in writing clear ideas, recommendations, and conclusions for their consulting project reports.

“The pyramid is a tool to help you find out what you think. I saw it meant there were only three logical rules to obey. The point above has to be a summary of those below because it is derived from them. You can’t derive an idea from a grouping unless the ideas in the grouping are logically the same, and in logical order.”

According to Tom Spencer, the MECE framework... Read more (20-minute read)

In a tragic aviation accident at Lumut naval base in Perak, Malaysia, two Malaysian navy helicopters collided mid-air during a practice session for an upcoming military parade, resulting in the deaths of all ten crew members. The collision, which took place around 9:30 AM local time, involved a Eurocopter AS555SN Fennec and an AW139 maritime operation helicopter. Following the collision, one helicopter crashed into a nearby sports complex, while the other fell into a swimming pool within the naval base.

Footage of the accident, verified by local police and circulating in local media, shows the helicopters flying in formation before one rotor clipped the other, leading to the catastrophic crash. In the aftermath, rescue personnel were seen managing the wreckage and debris on the ground.

The incident has prompted a full investigation by the Royal Malaysian Navy, supported by the Ministry of Defense, to ascertain the cause of the crash and to implement future safety measures. Prime Minister Anwar Ibrahim expressed his deep condolences to the families of the deceased, underscoring the national mourning for the lost lives. This accident is among several helicopter accidents in Malaysia in recent years, highlighting ongoing challenges in aviation safety within the region.

Read more (2-minute read)

Answered by Robert Halligan (PPI Managing Director and Course Presenter)

A quick test to get an indication is to ask yourself the following questions:

1. Do we make solution decisions that are significant to the success of our organisation? YES
2. Do our designs (solution decisions), when implemented in development, normally work the first time? YES
3. Do we have a significant incidence of rework in design due to errors made arising from design complexity? NO
4. Are we challenged to meet development schedule and cost imperatives and targets? NO
5. Faced with feasible design alternatives, do we have a quantitatively based, objective way of evaluating and selecting between these alternatives? YES
6. For a given solution concept, do we have a quantitatively based, objective way of converging in design on an optimum balance of product qualities such as various measures of performance, unit cost of production, reliability, etc.? YES
7. Do we have a quantitatively based, objective way of factoring risk into design decisions? YES
8. Is system integration (bringing our solution elements together to build in development a working solution) normally trouble-free? YES
9. Do our products/systems almost always compare favourably with those of our competitors or allies? YES

If the answers to these questions are mainly as shown, opportunities for improvement will lie mainly in technology improvements and breakthroughs, not in the organisation’s approach to design.

Read more FAQs

• 29 July—2 Aug 2024 ? | ??In-Person (United Kingdom)
• 29 July—2 Aug 2024 ? | ? Live-Online (North & South America)
• 5—9 Aug 2024 ? ?| ??In-Person (United States of America)
• 19—23 Aug 2024 ? | ? Live-Online (Asia & Oceania)
• 23—27 Sep 2024 ? ?| ? Live-Online (Europe, UK, South Africa, Middle East & Turkey)
• 21—25 Oct 2024 ? ?| ? In-Person (the Netherlands)