Why Conventional FMEAs fail too often, and why the Absolute Assessment Method FMEA is much better.

(Failure Modes and Effects Analysis)


On Oct 1, 2016, a commuter train crashed in New Jersey killing one and injuring 108 with high speed being a factor. The root cause of the crash is under investigation.

A similar crash happened in Amagasaki, Japan in April 2005 where 106 were killed and 562 injured, and high speed around a curve was a factor.  The conventional explanation of the root cause of the Amagasaki crash was corporate pressure on the driver to be on time.  Drivers would face harsh penalties for lateness, including harsh and humiliating “training” programs which included weeding and grass cutting duties.  In this case, the driver was speeding.  The resulting countermeasure in Amagasaki has been to put in an expensive $1-billion-dollar train speed control system on the small line to help mitigate a potential accident.

There have been many other high speed passenger train derailments, such as the Santiago de Compostela derailment in Spain in 2013 (79 dead, 139 injured out of 218 passengers), and the Fiesch derailment in Switzerland in 2010 (1 dead, 42 injured).  The root cause explanation of these accidents tends to focus on the drivers driving faster than they should, and countermeasures tend to focus on semi-automated systems to control train speed.

Do we really know the root cause of these accidents, and are the countermeasures both effective and economic?

One of the best root cause analyses I’ve seen on the Amagasaki crash comes from Unuma Takashiro, and his conclusion is unconventional.  Unuma-san is a Failure Modes and Effects Analysis (FMEA) consultant from Japan. FMEA is one of the best methods to analyze a design to help prevent failures.  FMEA was developed in the aviation and space industries in the 1960’s, adopted by the automotive industry in the 1990’s, and is now prevalent in many industries including health care.

Unuma-san argues that in the case of the Amagasaki crash, the speed control system is expensive and not fail-safe.  One economic and effective countermeasure would be to add a $250,000 guard rail, which at the very least would likely prevent a recurrence, and definitely be useful as an additional layer of countermeasure.  The advantage of low-cost and effective countermeasures is that they can be widely-deployed.


He argues the real root cause of this failure is that the overall engineering and management approach to mitigating failures was not adequate – both initially to prevent the accident in the first place, and subsequently after the crash by putting in the speed control system but not (also) the guard rail.

Unuma-san has a very interesting and useful website on FMEA practices, and uses the Amagasaki crash as one of many examples.  He promotes a FMEA method that uses an absolute evaluation method of countermeasures, as compared to the conventional FMEA which uses a relative evaluation method of countermeasures.  The problem with the relative evaluation method is that it can easily miss important failure modes that do not make an arbitrary priority cutoff.  Missing important failure modes often leads to unexpected incidents.

He also analyzes the conventional FMEA approach and teachings, and points out many problems seen in industry:

  • ineffective because of missing failure modes,
  • done too late in the design process, making it more difficult and less likely to implement countermeasures,
  • led by team members from other departments that are not responsible for the design, which both lowers the effectiveness of the analysis and can allow the designer to not be held fully accountable for the FMEA results,
  • doesn’t promote economical countermeasures, and
  • many of the common FMEA teachings contain flaws that promote the above problems.

Unuma-san shows that many FMEAs confuse failure mechanisms (the physical, chemical, thermal, electrical, biological, or other stresses leading to the failure mode) and the actual failure modes (ways a product or process can fail), leading to missing failure modes.  If a failure mode is missed, then there may be no countermeasure identified, and subsequently incorporated into the design.

He points out that the relative evaluation FMEA method promotes doing the FMEA on the entire design when enough of the design is done, then once the FMEA is done to a certain level, all of the issues are prioritized, and then acted upon.  The problem with this approach is that FMEAs take a lot of time, and by the time the results are done, the recommended changes to the design can be too late to be easily implemented.  He promotes instead that the designers do the FMEA as they are doing the design in a very concurrent and “local” manner, while evaluating the countermeasures in an absolute manner against the individual failure mode.  This more easily allows for countermeasures to get into the design of the product or process in the early stages.

When non-designers take too much of the FMEA responsibility and scope, the effectiveness of the FMEA is reduced and the results are available late in the design process.  The effectiveness is reduced because non-designers are unable to know all the key information in the heads of the designers, and the designers may feel less accountable for the FMEA quality.  Results are delayed because instead of countermeasures being considered at the time of the design decision, they are made available after the design decision has been made and it is then more difficult and less likely to have any countermeasure implemented.

Unuma-san’s method is simpler than many FMEAs, by using a four-point scale to the third power (64 ratings), vs. many conventional approaches using of a 10-point scale to the third power (1000 ratings).  He promotes determining countermeasures per failure mode, evaluating the likely success of those countermeasures, and whether there is opportunity for optimization and lower costs from reducing overdesign.

Unuma-san goes on to analyze the common teachings of FMEA by referring to many of the most common reference material available in books, training material, websites, etc. and he shows many flaws, inconsistencies, interpretation issues etc. that tend to exacerbate the above issues.  Much of the trouble with conventional FMEAs can be traced to poor teachings.

Unuma-san has consulted for a very long and impressive list of Japanese companies on FMEA in the transportation, health care, manufacturing, and consumer goods industries.

I’ve been both a lead designer of multiple complex systems, and I’ve been helping clients improve their product development processes, including FMEA.  The teachings of Unuma-san resonate strongly with me.  Too often I have seen poorly done FMEAs that miss critical failure modes, late FMEAs whose recommendations are too late to be useful, and FMEA study teams that don’t have enough participation by the design team.  The absolute evaluation method FMEA is a substantial improvement over the relative evaluation method, mostly because it evaluates the likely success of countermeasures.  I highly recommend his webpage on FMEAs, and it is linked here.  It is a little hard to read as the website translation to English isn’t the best, but worthwhile.

I think one of the reasons why FMEA teachings have many issues is that few FMEA teachers have been skilled design engineers, but are instead people that gravitate to process design.  The idea behind the FMEA is good and includes teaching early and effective analysis, unfortunately much of the applied practice falls short.  A skilled design engineer naturally considers failure modes and tries to design them out, while simultaneously considering many other design tradeoffs, such as performance, function, economics, aesthetics, ergonomics, etc.  I think that since the conventional FMEA trainers developed the applied practice of the FMEA, they have continued to build upon the original process of the relative assessment method, and have struggled to develop effective practices that overcome the conventional process shortcomings.  In my experience many design engineers have found FMEA to be a good idea but too slow, too time-consuming, and not effective enough to really embrace it.

What I like about Unuma-san’s method it is practical, effective, time-efficient, and evaluates the likely success of countermeasures.  It can be very useful to have FMEA experts, trained in this method, who can help designers with training, facilitation, documentation, review, etc.

There are a few other improved FMEA methods available that are trying to address some of the effectiveness and lateness problems with conventional FMEAs, such as “FMMEA”, (Failure Modes, Mechanisms, and Effects Analysis), and there are good teachings in these methods as well.  I have found Unuma-san’s method to be among the best and really resonates with me.

FMEA is one of the best methods to help avoid failures.  By making the method more effective, products, processes, projects, and infrastructure can have less problems and be more economical.  I highly recommend further study on this topic for engineers and managers delivering any system.

Craig Louie, P.Eng., Co-Founder, SysEne Consulting

A more useful Requirements Process Maturity Model

A useful diagnostic tool to help determine problem areas and areas for improvements are maturity models.  They can be used by both the client and consultant to determine the current level of performance.  The target level of performance doesn’t need level 5 (highest capability) for everything, as that is likely too expensive or difficult to achieve, or not necessarily needed.

One of the best ways of improving technology and product development is for your organization be good at developing and managing requirements.  About 70% of problems in technology and product development come from requirements and system interaction errors, and fixing these problems at the final acceptance test or in the customer’s hands costs about 100 times more than fixing them in the requirements development and management phases of the project.  Basically build the right thing, build things right, and find problems early.

For requirements development and management, there are a few maturity models published, but I have found them too specific to an industry (like for business analysts in the software industry), cover only certain aspects, or don’t cover integration, training, or culture well enough.  So I’ve developed the above model based on similar models from consulting houses, CMMI, Six Sigma, Model Based Systems Engineering, PLM, and my own background.  I think this can apply to all kinds of systems, from hardware-oriented (manufacturing, construction), software-oriented, or combinations of both.

Requirements Process Maturity Model

(click for full size)

Using this tool can then help structure the problem, ask the right questions and prioritize opportunities. Where does your organization stack up?

If you have comments or questions on the model, or have ideas for improvements, please contact me.





Tailoring Product Development Processes

There is a wide spectrum of product development processes, from stage gate to spiral processes.  Stage gate processes are able to stage scope and investment decisions and are typically employed in capital intensive industries.  Spiral processes take advantage of many repetitions of the design-build-test cycle and are typically employed in software development.  There are many variants in between.



To best tailor the product development process for the organization, it is important to understand the:

  • business and strategy of the organization
  • architecture and complexity of the product
  • product/project schedule, budget, and requirements
  • risks and uncertainties
  • needed iterations in the process
  • capability and culture of the organization, including Global aspects
  • customers, stakeholders, and suppliers
  • best practices

The resulting product development process is then “systems engineered” as it is an integration of systems and systems elements – technical, process, and people.

There are many useful methods to choose from during this design process, including:

  • Design Structure Matrix (Eppinger)
  • Agile Methods
  • Lean Methods
  • Model Based Engineering
  • Collaborative Supplier Integration
  • Risk-based Planning
  • Quality Approaches

A key aspect of product development is dealing with all the risks and uncertainties, which means iteration is inherent in the process.  There are both planned iterations and unplanned iterations (to fix it when it’s not right).  It is important to understand the linkages, interactions, and drivers behind how the iterations will happen.  From that understanding, iteration can be accelerated through information technology, coordination techniques, or decreased coupling.  After that, by prioritizing risks, planning the needed iterations, planning the integration and test activities, and scheduling reviews to control the process, the project risks can be addressed.

The process must also be tailored to the organization, specific people, and key stakeholders.  This is probably the most difficult part, as it is all about dealing with people, managing change, and shifting cultures.  It is important to pick and choose the most important methods, implement them, and sustain them, in a practical way. Too many processes fail because they are not used, unwieldy, inflexible, not fully coherent,  too conservative, too bureaucratic, take too many resources, or are only partly implemented.  Beyond process definition, there is training, coaching, fine-tuning, and ensuring the team sees that the change is in their self-interest to adopt, and really “owns” any new processes.

While overall improving the process is a complex and difficult initiative, having a competitive Product Development process is key to quality products, low costs, speed to market, satisfied customers, and good business.

How to Dramatically Improve Health Care; Speed, Quality, Costs

After my recent in-depth experiences with both the Japanese and Canadian Health Care systems, I’ve continued my investigation why the Japanese system has dramatically reduced wait times, better outcomes, and lower costs as compared to the Canadian system.  I have included the US system as well.  It is clear to me that applying systems engineering to health care will both improve the system and lower its costs.  When I experienced the Japanese health care system, I was so shocked at how much better and faster it was than the Canadian system, I wrote a post on it in Sept 2013, and I repeat one of the key tables here:


In Canada, the wait times for critical diagnoses are getting worse (see this recent article in the Globe and Mail).  Cancer diagnosis can take 1 to 6 months (!!!) in BC whereas in Japan it can often be done in one day.

The US is getting serious about applying Systems Engineering to their Health Care System.  The White House’s President’s Council of Advisors on Science and Technology (PCAST) has published an excellent report in May of 2014 called “Report to the President, Better Health Care and Lower Costs: Accelerating Improvement through Systems Engineering”.  The Report is an excellent read and is surprisingly bold in its recommendations.   One of the main recommendations is to transition from a fee-for-service model, which is a disincentive to efficient care, to one that pays for value instead of volume.


Health Care Systems are very complex, with evolving medical science and technology, multiple stakeholders, increased specialization, and rising expectations of what can be done to treat illnesses, and a lot of realpolitik.  Systems engineering has been used successfully and widely in many other complex industries, such as manufacturing or aviation.  Systems engineering has also been used to good effect in health care, but too rarely and not widely, and barely at all on the macro scale.

The need to improve health care is required, with increased population, aging, and budgetary pressures.  The opportunity for improvement is massive.  In the US, approximately 33% of health care costs are wasted, 20-33% of hospitalized patients experience a medical error with about half of them preventable, many quality issues, and caregivers and patients do not have enough necessary information when needed.  In Canada, we see many of the same issues as the US, and while we have Universal coverage, wait times for necessary diagnostics or treatment are unnecessarily and often crazily long.  Even in Japan, with its worldwide overall best outcomes, low costs, and low wait times, significant improvements are possible in overall efficiency, information flow, costs, and caregiver conditions.

Examples of how systems engineering can improve health care include:

  • Denver Health saving $200 million in 2006 by doing a systems redesign of their operations. As an example to reduce waste, one industrial engineer found the trauma surgery resident physicians walk 8.5 miles in a 24 hour shift!
  • Kaiser Permanente identified 3x as many sepsis cases and cut mortality from sepsis by 50%
  • Virginia Mason has the lowest rate of serious medical infections and falls and reduced medical malpractice liability by 40%

 Systems Engineering Processsystengprocess

How impactful could systems engineering be if applied at all levels of Health Care? The promise is outcomes as good as Japan or the top tier American care, Universally applied, and lower costs to Government and Patients, with essentially no wait times.  It won’t happen overnight, but with the right strategy we could get there in 3-5 years. It is very feasible – if others can do it, we can too. That will then allow us to also be prepared for the greying of our populations.  It is good business too, as the improved systems can be exported to other parts of the world.  When you have a good system, look how it can dominate the market – like Amazon with its great portal, logistics, and network; or the Internet, with its scalability and extensibility, or air travel with its convenience, low costs, widespread usage, and high safety.

The best studies on how to improve health care by applying systems engineering tools and principles comes from the US.  An excellent paper and collection of studies was published in 2005 by the combined efforts of the National Academy of Engineering and the Institute of Medicine called “Building a Better Delivery Systems, a New Engineering/Health Care Partnership”.  I highly recommend this paper.  Much of this material formed the basis for the 2014 PCAST report to President Obama.  Yet one of the last papers in this collection highlights the real difficulties with making improvements in the US Health Care system by analyzing and giving painful examples of the political difficulty, especially with so many interests, organizations and the huge amount of money in the Health Care systems.

Other barriers include:

  • Misaligned incentive structure – fee-for-service vs fee-for-outcomes or value
  • Availability for data and relevant analytics
  • Limited technical capabilities, especially in small practices that make up the bulk of health care
  • Workforce competencies – limited knowledge of systems engineering tools and practices
  • Leadership / culture / politics

Yet while difficult, governments, organizations, and people around the world understand the need for change, the urgency for change, and that there will be change in Health Care.  It is hard work, it will take time, and there are many barriers, especially politically.  Slowly and steadily, I expect systems engineering tools, principles, and activities to be applied into the Health Care system.  You can help by reading the PCAST and other reports and supporting the application of Systems Engineering to Health Care.

For me, I am approaching Industry, Government and Academic leaders with this message and analysis, participating in consultations, etc.


Improving Systems Education and Research at Canadian Universities

In today’s world, products and processes are becoming more complex, and systems engineering is the best method to manage change and complexity.  Students that have academic and experiential capability in systems engineering will be more useful and attractive to potential employers.  Universities that provide a strong program in Systems will attract better students and improve academic and industry collaborations.  Industry and Government will benefit by improved systems development.


Engineering education worldwide has begun to broaden from preparing students for technical careers in a particular discipline to also prepare technical leaders that will develop complex systems or have their “subsystem” fit better into the next higher level system.  Engineers today are expected to be capable in management concepts and social science that encompass supply chains, politics, economics, and customers.  The leading Universities have made cross-functional organizations that often combine engineering, management, and social science into “Engineering Systems” systems-oriented schools.  These organizations can better cut across the more siloed traditional disciplines to offer integrated systems education and research which benefits from discipline fusion.

The forefront of the Engineering Systems Education and Research Universities include MIT ESD, Georgia Tech ISyE, Stevens SSE and SERC, Keio SDM, TUDelft TPM, and others.  There is a Council of Engineering Systems Universities (CESUN) that helps coordinate the development of this field of study, with about 60 universities as members.  SFU and the University of Waterloo are members of CESUN.

engineering systems

Overall I find much of the best Systems content comes from MIT Engineering Systems Department and associated community, such as from Steven Eppinger, or their book on Engineering Systems by de Weck, Roos, and Magee.  There is a lot of other great material out there from many others, but if I had to choose the best Engineering Systems University program, it would be MIT’s ESD program.  MIT’s ESD Strategic Plan is a worthwhile read.  To also see that other regions are also at the forefront of Systems education, the “SDM in Two Minutes” video from Keio University’s program is also worthwhile.

There is also strong Systems Engineering Professional Education Programs available from places like Caltech or Georgia Tech, as many organizations send mid-career engineers, project managers, business analysts and management to these programs.  INCOSE, the International Council of Systems Engineering also provides links to training and certification as a Systems Engineering Professional, again primarily for professionals in the workforce.

The Systems Engineering discipline primarily came from Industry and Government, especially Defense and Aviation, and is now grown to be applied to develop and manage the complex systems in Energy, Transportation, Health Care and other industries.  Both the Systems Engineering Professional Education and the University Education in Engineering Systems are complementary and synergistic.

Universities that provide Systems education provide Undergraduate programs, Graduate programs, or Professional Certificate programs, or a combination of all three.  Undergraduates with Systems education are able to become useful as a Systems Engineer right away. Charles Wasson makes a great argument for comprehensive systems engineering training at the undergraduate level to all engineers in this paper. At the same time, it can also be good to become well educated in one of the disciplines, like Mechanical or Software Engineering, and then take a Graduate degree in Systems, often with some work experience in between.  Many engineers in the workforce find that their background in one of the disciplines is not enough for being a leader in developing complex multi-disciplinary systems, so they return to get either a Graduate degree or take Professional courses in Systems.  The average age of students in MIT’s System Design and Management Program is 34, reflecting more mature students.


The Canadian University Programs in Engineering Systems or Systems Engineering are not as well developed as the leading Universities in this field.  UBC and SFU have undergraduate programs in Integrated Engineering and Systems Engineering respectively, and both are a good first step towards multi-disciplined engineering, but neither school has a Graduate Level or Professional Programs, and the current curriculum does not generally include the Systems Engineering fundamentals or have the same level of fusion with social sciences or management science as in other leading Universities.  SFU’s program is more of a Mechatronics program than what Systems Engineering is typically known for.  The University of Waterloo has perhaps one of the best Systems program in Canada, with their System Design Engineering program, which is both Undergraduate and Graduate level, though it has a flavour of more “subsystems engineering” than “macro systems engineering”.  Concordia also seems to have a good Systems program, graduate level, and focused on Information Systems.   U of T has a graduate certificates in global engineering or multidisciplinary engineering final project programs, but the bulk of instruction is still in the traditional disciplines, and there isn’t the same level of Systems education or Research as the leading Universities.  Overall for Canadian Universities there is a good start but there is much room for improvement.

Note there is a large diversity in the naming of these “Systems” programs, as to a certain degree, each University likes to brand their program as unique.

In my home region of Vancouver, there are many local companies that heavily use systems engineering in their development.  They include MDA, Westport, Ballard, and many small tech start-ups.  They have all had to teach the Systems Engineering discipline by bringing in external resources, as BC graduates don’t come with much Systems educational background.  For future BC developments, such as a new LNG plant, or improving our Health Care System, Systems Engineering is of great benefit.  In the rest of Canada, we have world leading companies like Bombardier, GE Canada, SNC-Lavalin, Cisco, and Blackberry that all heavily use Systems Engineering.

Canada is shifting from a more Resource-centric economy to more of a Knowledge-based economy.  One of the most effective pillars to do that is to ensure Canada has a very strong systems-centric engineering education at our academic institutions to complement the traditional disciplines.  Canadian Universities must improve their Systems education and Research.  There are great examples by the leading Universities that Canadian Universities can incorporate.

While these changes are difficult to do, because it requires organizational changes, there can be tenure and political issues, there are fixed budgets and five year plans already in place, and it can be hard to fuse departments between different faculties of Engineering, Management, and Social Science – the incredible benefits of improved Systems education to Canada, the Provinces, Industry, Students, and the Universities is well worth the investment.

Is your Complex System Project on track for Ultraquality Implementation?


We expect complex systems like an airplane, a nuclear powerplant, or a LNG plant to practically never fail.  Yet systems are becoming increasingly complex, and the more components there are in a system, the more reliable each component must be, to the point where, at the element level, defects become impractical to measure within the time and resources available.

Additionally, in future, our expectations will increase for complex systems durability, reliability, total cost of ownership, and return on investment, as energy and raw materials increase in cost.

Ultraquality is defined as a level of quality so demanding that it is impractical to measure defects, much less certify the system prior to use.  It is a limiting case of quality driven to an extreme, a state beyond acceptable quality limits (AQLs) and statistical quality control.

One example of ultraquality is commercial aircraft failure rates.  Complexity is increasing: the Boeing 767 has 190k software lines of code, whereas the Boeing 777 has 4 million lines of code, and the Boeing 787 about 14 million lines of code.  The allowable failure rate of the flight control system continues to be one in 10 billion hours, which is not testable, yet the number of failures to date is consistent with this order of magnitude.


Another example of ultraquality is a modern microprocessor, which has the same per chip defect rates despite the number and complexity of operations have increased by factors of thousands.  The corresponding failure rate per individual operation is now so low to be almost unmeasurable.


What are the best practices to achieve ultraquality in complex systems?

Meier and Rechtin make a strong case that while analytical techniques like Six Sigma and Robust Engineering Design will get you close, the addition of heuristic methods will get you over the top.  This includes using a zero defects approach not only in manufacturing, but also design, engineering, assembly, test, operation, maintenance, adaptation, and retirement – the complete lifecycle.

There are many examples how analytical techniques alone underestimate failure; for example the nuclear industry analysis of core damage frequency is off by an order of magnitude in reality.


A sample of applicable heuristics include:

  • Everyone in the production line is a customer and a supplier [also extended to each person in the development team – engineering, supply, etc.]
  • The Five Why’s
  • Some of the worst failures are system failures
  • Fault avoidance is preferable to fault tolerance in system designs
  • The number of defects remaining in a system after a given level of test or review  (design review, unit test, system test, etc.) is proportional to the number found during that test or review.
  • Testing can indicate the absence of defects in a system only when: (1) The test intensity is known from other systems to find a high percentage of defects, and (2) Few or no defects are discovered in the system under test.


[pie chart courtesy Boeing.  FBW = Fly By Wire]

There is a lot more material on “how-to” in the works of Meier and Rechtin, Juran, and Phadke.

Ultraquality requires ultraquality throughout all the development processes, and by extension throughout the delivering organization.  That is, certify a lack of defects in the final product by insisting on a lack of defects anywhere in the development process.  Developing both the processes and organization to achieve this state is possible, is being done in some organizations, and allows for superior business performance.

There are many examples how organizations lack ultraquality in their processes or organization.  General Motors is under heavy criticism these days following the Valukas report, which exposes the poor organization and development practices.  This is anecdotally impacting the GM dealers and turning them into ghost towns.

So back to the tagline: is your complex development project on track for ultraquality implementation?

Model Based Systems Engineering Readiness for Complex Product Development


The increasing nature of complexity of today’s systems and systems-of-systems make it increasingly difficult for systems engineers and program managers to ensure their product satisfies the customer. As an example, in this year alone, General Motors has recalled more vehicles in the US than it made in 2009 to 2013 – and it is only May!


May 21, 2014, http://www.huffingtonpost.com/2014/05/21/gm-recall-more-than-sold_n_5367478.html

Over the past 5-10 years, a formal discipline of Model Based Systems Engineering (MBSE) has been developed by the Systems Engineering community to catch up with rigorous model tools available to the other domains, such as CAD/FEA for mechanical engineering, or VMGSim/Hysys for chemical engineering, or C++ code generators for software development.

The combination of increased complexity, increased domain model usage, and drive towards virtual product development and simulation capability have made it very difficult to make sure there is consistency in all the models, documents, and data sets for a complex product.  Without one single truth in the data set, there is increased likelihood of downstream problems.  MBSE is now in a position to allow systems engineers develop a rigorous coherent flexible system model that can be an integrating design and development function across the program lifecycle, enabling this future vision:

mbse vision

Source: INCOSE MBSE Workshop, Jan 2014

The main benefits of MBSE are:

  • Reduced rework, earlier visibility into risk and issues
  • Reduced cycle time, reduce development cost, cost avoidance
  • Better communication and more effective analysis
  • Potential for increased re-use (product line reusability: engineering done once, reuse elsewhere)
  • Ability to generate and regenerate current reports and work products
  • Knowledge management (long-term and short-term)
  • Single source of truth
  • Competitiveness (our partners and competitors are doing it)
  • Think about how much of an engineer’s time is spent on data management rather than critical thinking (Change that ratio! Shift the nature of my hours)

While models have always been a part of the document-centric systems engineering process, they are typically limited in scope or duration, and not integrated into a coherent model of the entire system.

MBSE uses a graphical modelling language, called SysML, which is an extension of UML (Universal Modelling Language) developed by the software industry.  The SysML language and a MBSE modelling tool allow systems engineers to develop descriptive models of the system.  As an example:

sysml model

Source: INCOSE MBSE Workshop, Jan 2014

There are several MBSE tools available, Rhapsody (IBM), MagicDraw (No Magic), and Enterprise Architect (Sparx).  These tools have been successfully been used by companies like Ford, Boeing, or Lockheed Martin, and they continue to improve.  MBSE is still relatively early in development as compared to other domain tools, like CAD, FEA, or PLM (Product Lifecycle Management), but is now at a stage that it can have an immediate impact on the developing system.  There are many connecting tools to PLM tools or Requirements Management tools like Rational DOORS or other disciplines.

I have found it really tough (and to a certain degree impractical) using the document-centric systems engineering approach to keep all the various design documents and models up to date and consistent with each other.  I’ve been using MBSE tools from both NoMagic and Sparx, and they are both pretty good at capturing all the necessary systems engineering information in one model.  There aren’t many good tutorials and examples available to the public domain, but still enough to learn from.  I have been able to steadily and productively apply MBSE to my system design and analysis work.

I highly recommend any organization that is doing complex product development to consider MBSE.  It is the future for fast and high quality product development.


Insight and Heuristics in System Architecting

 One insight is worth a thousand analyses

iron man simul

-Engineering and Art: Iron Man 3

Systems Architecting is as much art as it is science.  The best book on this subject is from Maier and Rechtin, and I highly recommend it.


-Maier and Rechtin, The Art of Systems Architecting, second edition, CRC Press, 2000

One of the best section of the book deals with using the method of Heuristics in architecting.  Insight, or the ability to structure a complex situation in a way that greatly increases one’s understanding of it, is strongly guided by lessons learned from one’s own or others’ experiences and observations.  Given enough lessons, their meaning can be codified into “heuristics”.  Heuristics are an essential complement to analytics.

As in the previous post, where the system engineer is to consider the whole and apply wisdom, Maier and Rechtin also promote the use of wisdom but they note that “Wisdom does not come easy”

  • Success comes from wisdom
  • Wisdom comes from experience
  • Experience comes from mistakes

While required mistakes can come from the profession as a whole, or from predecessors, it also highlights the importance of systems engineering education from those skilled in the art.

Examples of heuristics are:

  1. Don’t assume that the original statement of the problem is necessarily the best, or even the right one
  2. In partitioning, choose the elements so that they are as independent as possible; that is elements of low external complexity and high internal complexity
  3. Simplify. Simplify. Simplify.
  4. Build in and maintain options as long as possible in the design and implementation of complex systems.  You will need them.
  5. In introducing technological and social change, how you do it is often more important than what you do
  6. If the politics don’t fly, the hardware never will.
  7. Four questions, the Four Whos, need to be answered as a selfconsistent set if a system is to succeed economically; namely, who benefits?, who pays? and, as appropriate, who loses?
  8. Relationships among the elements are what give systems their added value
  9. Sometimes it is necessary to expand the concept in order to simplify the problem.
  10. The greatest leverage in architecting is at the interfaces.

-taken from Maier and Rechtin, The Art of Systems Architecting, second edition, CRC Press, 2000

 Heuristics are tools, and must be used with judgement.  The ones presented in the book are trusted and time-tested.  They may not apply specifically to your complex systems architecting work, though I think you will find most of them do.

Just Enough Systems Engineering

I’ve been putting together a teaching course on Systems Engineering, and I came across a gem of an eBook by Dwayne Phillips, called “Just Enough Systems Engineering”.  I have found it very useful reference to help me develop the course, as it is filled with systems engineering wisdom.

Sys Eng Enough?

There is large amount of systems engineering material available from various sources – from Incose, many books, many presentations, and many research papers.  It can be hard to summarize the large body of knowledge into a useful teaching course.  I find this eBook unique in that is comes from the angle of how to use systems engineering practices from a very practical perspective.   And it is free!


There are many quotations in the book that I find very useful:

What does a systems engineer do?

“The systems engineer examines the entire system and applies a little wisdom.”

I think this is a good perspective as it helps simplify a very complex topic and help a practicing systems engineer remember the importance of using good judgement, which typically comes from experience – both of the practicing engineer, and any learnings from the experience of others.

When and how much systems engineering to apply

“Use systems engineering when the system and project are bigger than any two people.”

The importance of asking questions in the best way

“Here is where much of systems engineering collapses.”

Systems engineers have to work with a wide variety of people –the client, the builder, the development team, etc., and asking questions of these people in the right way is a key skill.  Many engineers have very strong problem solving skills.  A systems engineer also needs strong people skills, and this eBook has a wealth of material on how best to ask questions in the systems engineering context.  I haven’t found any other references that explain this angle well, and give very practical suggestions on how to succeed.

For anyone interested in becoming a better engineer, I highly recommend this eBook.

Systems Approach to Health Care

Applying a systems approach to health care significantly improves quality, speed, economics, and customer satisfaction.  I have now experienced both the North American and Japanese Health Care Systems, and I can now see the clear benefits of the systems engineering approach applied to technology, activities, and people (i.e. using the Design Structure Matrix approach).

Figure 1 Personal Hospital Pager, Japanese Hospital

Figure 1 Personal Hospital Pager, Japanese Hospital


When you are a patient at a Japanese Hospital, you get a Personal Hospital Pager, so they can immediately notify you of your next diagnostic or consultation appointment and potentially slot you in earlier.  Japanese hospitals operate like a modern manufacturing plant or logistics center with a fully integrated Information Technology System with all scheduling and results and reports in the digital domain.  Japanese hospitals have all the diagnostic procedures in the hospital – MRI, CT, PET, etc., and the waiting times are so short, there isn’t really a wait time.  The doctor is able to order all the necessary diagnostic or treatment procedures from her PC and you basically go from one station to another in the hospital all in one day.


Figure 2 Personal RFID Card and Diagnostic Schedule

Figure 2 Personal RFID Card and Diagnostic Schedule


As a patient, you also get a Personal Card with a RFID chip that stores key data (Fig 2, middle left) and a printout of your daily schedule, in this case seven diagnostic or consultative events.  In Canada, it is often weeks between each event, and sometimes much longer, such as for a MRI or CT scan.

From a patient perspective, the speed and very short delay times is both comforting, and must increase the likelihood of successful treatment for any degenerative disease.  From a macro perspective, a comparison of health care systems bears this out.

Figure 3 Health Care Systems Comparison

Figure 3 Health Care Systems Comparison


What is striking for Japan is the relatively low health care expenditure, good results in life expectancy or infant mortality, the high amount of diagnostic equipment, the number of hospital beds with a typical nurse count, the low amount of “out-of-pocket payments”, and the short wait times.  A MRI here is about $100, vs. $1500 in the US.  For major surgery, in Canada you stay in the hospital for 5-6 days, in Japan, you come in 2-3 days before and you stay 21 days until they are really, really, sure you are ok (with lots of diagnostic tests).  Patients that have experienced both the Canadian and Japanese system very much prefer Japan.

How can the Japanese System be so good and efficient?  While Japanese people may be more fit and have a better diet than North Americans, they are also one of the fastest “greying” populations, and smoking is more prevalent in Japan than in North America.  After experiencing this system first hand, the high level of integration, full information technology system, modern logistics/manufacturing process, competition between hospitals, and overall design of the system to keep results high and costs low, have forced process innovation in the right areas.  Is the Japanese System perfect?  Not by any means, but compared to North America, it is at another level.

There is great benefit to applying the systems approach to any system.  In case of the Japanese Health Care System, it even includes ensuring the political side is appropriately managed.  When the Japanese physicians tried to game the system by ordering more MRI’s, the next year, the Japanese Government lowered the MRI fee by 35%.

Figure 4 Automatic Reentry

Figure 4 Automatic Reentry


While there are many administrators and health care professionals and technicians at a Japanese Hospital, there are also automated kiosks everywhere for many procedures, such as checking-in, paying any out-of-pocket expenses, urine tests, etc. which makes the whole time spent at the hospital very smooth and efficient.  You put your Personal RFID card from Figure 2 into these kiosks, complete your procedure, your card and file is updated, and move onto the next station.

For Health Care, the system design is kind of easy.  We experience full IT tracking systems in our daily lives, like Amazon.com’s reviewing, inventory, purchasing, and packaging tracking systems.  We know that modern manufacturing process logistics systems exist.  We have ways of measuring results, like outcomes, wait times, or customer satisfaction.  Japan has integrated these best practices into a low cost system.  It is just good business, and a good human system.  North America needs to shamelessly borrow this better system from Japan, and tailor and improve where necessary, as was done with the Taguchi Quality method etc.