INCOSE Corporate
Directors Award
President Award
Bronze Circle Award
Silver Circle Award
Gold Circle Award

When System Engineering Goes Rogue

by George Anderson on February 1, 2011  •   Print This Post Print This Post   •   

ISO logo ISO 15288 represents to many systems engineers a pinnacle of achievement in defining not only a life cycle framework for man-made systems but also the practice of SE in general. If the processes in this standard are used as defined, organized and purposed, one would expect to see a drastic improvement in the performance, suitability and increased customer utilization of modern systems. While measures of performance themselves can be subject to variation, several areas of concern might serve to illustrate where we could improve this standard to the continuing benefit of mankind.

A good example of missteps, or at least some designer fibrillation, can be seen in the ubiquitous clock as it has evolved in the modern aircraft instrument panel. Most of us have marveled at the complexity of instruments in modern aircraft and can appreciate the need for standardization, readability, reliability and information content as key requirements. How can the clock be improved in these areas?

It turns out that it’s a tough job.

A13 ClockThe mechanical clock has been improved over many development cycles. The aircraft instrument panel clock benefits from this history and a current model is shown in the adjacent figure. This clock design is the military A-13 series and features a round dial, stopwatch function and two control inputs. The clock is driven by a mechanical mechanism powered by a spring and accuracy is provided by a precision oscillating balance wheel. At least three generations of pilots have been accustomed to using this instrument for timekeeping and as an integral part of conducting instrument approaches. This last item suggests the necessary role that the clock plays in safely completing a flight. Clearly, no compromises can be made with readability under adverse conditions and the mechanism must be unaffected by other systems malfunctions.

Digital electronics with its flexibility, low cost and availability has been used to produce replacement clocks. The figure below shows a typical example. One does not need to be a pilot to have some misgivings about this display. Where, for instance, does the pilot make time comparisons, note rate information or view spatial references? A part of the pilot’s world is referenced to the visualized clock face as a surrogate for a spatial reference system based on azimuth and distance from a central point:

  • “Traffic at your two o’clock position moving from right to left”
  • “The generator is mounted on the case flange located at the 4:30 o’clock position as you face the front of the engine”
  • “Check your six for bogies”

Fortunately, digital electronics can drive clock hands just as well as mechanical oscillators and so we have newer displays that are returning to the original designs and even include the same mechanical knobs vs. the vague little buttons. Abandoned, thankfully, is the temptation to put a voltmeter on the same face. I think the industry has dodged a serious error here, and the public seems to agree. Digital instrument displays in general are not popular in racing cars, while wristwatches with dials derived from older military designs are a commercial success. Unfortunately, the FAA has lagged behind in this area by approving the use of digital clock displays in the cockpit without establishing or referencing meaningful design standards. <FAA Advisory Circular 20-94A, 4/13/2007>

Technology can be a double-edged sword. It provides new capabilities but can, if not managed properly, take away others. Is new always better? Does the requirements process properly identify all solution sets? Do developers have any experience and historical context in the area or industry that they are now working? These and other questions must always be answered as part of the development process.

What about another area involving standard practices related to systems safety? ISO 15288 as currently written leaves this as an exercise for the engineer to address during decomposition of the engineering tasks. Some help and perspective can be found in the various treatments of Murphy’s Law. The Murphy’s Law series is probably one of the most influential sources of safety insights in use today. An original statement of the law is:

  • If an aircraft part can be installed incorrectly, someone will install it that way.

This is just the beginning of the concept and many corollaries have been added to what can be an extremely valuable safety compendium.

While Murphy’s Law began in the aerospace industry, other areas of systems engineering, especially information systems design, are notably deficient in addressing similar issues. Some of the corollaries paraphrased from a 1970’s era safety magazine for USAF fighter pilots, should illustrate the point well:

  • Man who has choice, has troubles – Confucius
  • Interchangeable parts won’t.
  • Availability of a part is inversely proportional to the need for the part.
  • After a device has been fully assembled, extra parts will be found on the bench.
  • Any safety factor set as a result of practical experience will always be exceeded.
  • The most logical way to accomplish a task will be the wrong way.
  • The necessity for a major design change increases as the job nears completion.
  • A fail-safe circuit will destroy others.
Fine Airline 101 Crash 1997
Murphy’s Law Repeated: Fine Air DC-8 Crash at Miami International Airport, August 7, 1997
  • Hermetic seals will leak.
  • A failure will not appear until the part has passed final inspection
  • If a wrong publication can be used, someone will use it.

Safety and associated good design, is a vague thing until experts start sorting through the accident wreckage or listen to the last minutes of a cockpit voice recorder on a doomed aircraft. Some design flaws like the ones surrounding the clock are harder to find than those associated with the hardware failures commonly treated in Murphy’s Law. Regardless, ISO 15288 should be expanded to include better task guidelines at the requirements stage of the product life cycle and thereby prevent future examples of those lessons already learned.

Previous post:

Next post: