Showing posts with label Engineering systems. Show all posts
Showing posts with label Engineering systems. Show all posts

Friday, October 23, 2015

Mars One Needs a Dose of Reality in the U.A.E


I'd taken a stand not to spill digital ink about Mars One on this blog. That was until two days ago, when the crew of Dubai Eye 103.8 - Alex Hirschi and Tim Elliot - invited Mars One chief Bas Lansdorp to speak on the evening's Drive Live show. I started to shake my head. 

In 2014, Mars One had pinched some local nerves when the grand mufti of Dubai issued a fatwa (an Islamic ruling) prohibiting Muslims from being volunteers for one-way interplanetary travel.

But on the radio show, there was little sign of defeat. With continual praising of the U.A.E and it's forward thinking stance, Mr. Lansdorp's tireless dance for manned one-way trips to Mars might have gotten more than a few listeners, albeit expats, breathless. 

And those listeners might be forgiven. Afterall, October was the month when NASA hyped a bit about the presence of liquid water on Mars. Ridley Scott had also released The Martian, an entertaining but pseudo-scientific space survivalist movie about a lone astronaut fighting for his life on Mars in the wake of a fairytale dust storm.

Mr. Lansdorp wasn't here to merely get cozy with two U.A.E volunteers he'd shortlisted as potential crew members for this future "mission". As it's becoming painfully evident, Mars One is around $15 million short of funding, and it's come to bear that some of it's money making strategies didn't help.

An intelligent listener would have recalled that Mr. Lansdorp had recently admitted at a Mars Society face-off with an MIT team (who happily demolished him for the seemingly brazen lack of any feasibility in the $6 billion dollar mission plan) that Mars One doesn't have the financial capability currently to pay any credible scientific group to undertake full-fledged R&D studies.

The other cat that jumped out of the bag in the same debate with MIT was that, as of August 2015, the Mars One mission had no fixed project scope, no fixed project time-line and no fixed project cost. It was evident that he had little concrete to offer in the rebuttal of MIT's independent feasibility assessment. Unfortunately, Mr. Lansdorp's weak conclusion that day was : "The Mars One mission is not to do the mission the way as it is exactly described on the website."

Sadly, none of his comments from the debate have been posted as an updated disclaimer on the Mars One mission road-map. The "plan" continues to hold that it will send one way manned missions every two years to Mars beginning in 2026. 

Why, pray, is there a need for Mars One if it's own chief calls into questions the Mars One plan? Might it be wrong now to assume that several hundred patrons might have been duped?  I won't be trying to answer how these people justify their return on investment in this case. It's really fuzzy.

But now you say hindsight is 20/20, that I'm just another naysayer piggybacking on the MIT study. While I understand any technical product will not sell without a strong commercial proposal, Mars One is awfully lacking in the former. One wonders whether Mr. Lansdorp truly stays awake at night as he fishes out new reasons to try and oversell this plan, particularly in the U.A.E.

At this point, I'd like to state two things in my analysis. One, I find interesting, is that the Mars One chief appears to take pleasure in bashing NASA's seemingly slow MARS schedule as the basis for his role in introducing Mars One.  

To be honest, this can be forgiven on NASA's part for the U.S Congress' space exploration budget cuts in the recent past. NASA must also get a bit of the benefit of doubt because it follows a prudent systems-validation based approach to assessing technical feasibility in putting people and equipment in space. 

Secondly, Mr. Lansdorp appears to be fixated on a misunderstanding that the Apollo Lunar program had virtually nothing to show technically when Kennedy made his 1961 speech spurring the moon mission. On this basis, he seems to be telling everyone that his Mars One plan deserves a chance as well.

Never mind the fact that the Apollo manned moon program had some 12,000 companies, 400,000 people and a backing of $25 billion to make it happen. Never mind the fact that it had no less than 33 flights, 22 of which were unmanned missions to specifically qualify the launch vehicle and spacecraft for manned flight and 4 of the 11 total manned flights were to man-rate the final 7 flights for lunar missions. Also, never mind the facts that NASA had the Saturn rockets going for them and the genius in Wernher Von Braun to provide technical advice during those years.

What a lot of people will tend to the forget is that the real need for an Apollo mission to the moon was never really scientific. The strongest impetus for Apollo was the uncompromising competition the Americans had with the Soviets in the space race. The Soviet secrecy around it's own space program never made the Americans comfortable that they were any ahead in this race, even to the very day Apollo 11 launched. Rational or irrational, this conveniently placed call of the Cold War captured hearts and minds and turned a nation on it's heels.

In short, yes the moon mission was extremely risky but NASA had a big part of the workable solution already in it's arsenal, which they tested the living daylights out of. They managed out risk. They also had a resounding patriotic call to arms behind the moon endeavor. Both of these are truly lacking in the Mars One plan. 

Mars One, as it currently stands, calls for taking ordinary people on a never-to-return one way trip to Mars in 2026. Due to the nature of this mission, one might be right to assume that these people are to live dull lives to their deaths as technicians - building, fixing and repairing technology - in a mega experiment that has seldom been tried before.

One has to appreciate Bas Lansdorp's energetic parade going around the world flaunting Mars One. But I believe it would be in his best interests to remain truthful about the project realities, re-assess his technical and cost plans and make modifications in the light of technological and procurement readiness. Right now, the Mars One plan rests, at best, on faulty and misleading data.

There are the geo-political challenges of an Outer Space Treaty. In this regard, I predict Mr. Lansdorp will have little option but to sooner or later join hands in cooperation with the rest of the world's space agencies. Countries aren't going to be friendly knowing that a single entity might potentially monopolize the exploitation of areas of Mars, which by his own admission on 103.8,  is a behavior that cannot be controlled from earth once the mission has landed on the planet.

No less important are the unsaid conflicts of interests in demanding the unquestioning service of human volunteers in such a short time and cozying up with investor driven business commitments and schedules. 

We're lacking in the long term understanding of planetary group survival through a longitudinal study here on earth. Some papers written after outpost like simulations exist and do not paint a pretty picture. A 2009 paper by the Mars Society on stress and coping in a 4 month arctic Mars simulation on Devon Island in Canada concluded, very subtly :

"Stress increased for males while decreasing for females. Males consistently used more avoidant coping while females utilized task coping and social emotional coping. Males also demonstrated higher levels of excitement, tiredness, and loneliness. Simulations situated in environments characterized by prolonged real isolation and environmental challenges appear to provoke true demands for adaptation rather than temporary situational accommodation as has been evidenced by shorter simulations in laboratories or more benign environments".

We're yet to take this further and quantify the human capability to cope under long term duress. Hollywood cannot dictate how you will eat , drink, procreate (or whether babies will be mutation free), romance, control criminal behaviors and so on. These have to be tried and tested in environments as close as possible in conditions to Mars.

I doubt the leaders of Mars One will not know all this, but the exploration of U.A.E to build an outpost, where temperatures climb to 45 degree C in summer, is rather strange. More to the point, how this plays out in the context of an active fatwa is a mystery.

Never to be one taken by hype, I stand cautious of the Mars One adventures. There's a lot of things to make Mars One flop. But there's a huge room to correct mistakes now.

Friday, March 14, 2014

Systems Failures : Lessons from Aviation


The F-16 was the first fighter aircraft purpose-built to pull 9-g maneuvers, all by Fly-By-Wire

Mysteries pull the human mind. And few things can be so mysterious as a 777 airliner that is roughly 200 ft long and weighing around 600 tons disappearing from the radar without a trace. Six days into the MH370 disappearance, investigators from more than 10 countries have not located it physically but they are chasing clues.

Searching for premature answers is understandable in aviation disasters. An airplane is a highly valuable asset to any nation and a tool for international development and international diplomacy. It is an agent of globalization, like trucks and ships and helps build economies. The passing of a flight from one country's borders into another has behind it possibly thousands of pages worth of treaties, policies and communication protocols.

In a post 9/11 world, the world is sensitive to another Mohammad Atta turning off an airplane transponder and steering it into buildings of economic importance. The image of an aircraft being used as a suicidal missile to launch fundamentalist propaganda remains fresh in the mind.


Aviation Accidents As a Systems Failure

The days since MH370's first disappearance plays out unsurprisingly like the Air France 447 saga. People said lightning caused the carbon composite body to rupture.  Some others revisited bomb threats made against the air liner months before the incident. A few entertained catastrophic electrical system failures because of the thunderstorm it flew through. The aircraft had flown through a military territory, did it get accidentally shot down?

Of the various root causes leading to the death 228 people, few imagined that an airspeed indicator (pitot tube) that was designed rigorously to certification tests would fail its function. Fault Code "34111506" had drawn first blood.


Discussion of the AF447 ACARS reading shown on French television

But the accident, they say, was still preventable. After ice crystals began developing on the pitot tubes, instruments began giving erroneous readings inside the cockpit. Autopilot gave up, turned off and the aircraft was in manual fly mode.

Making matters worse, at the time around this circumstance, the captain was in the back on his customary rest period and the least experienced of the three pilots had primary command of the airplane. Both co-pilots didn't recover from their lack of orientation, let alone practice proper flying etiquette. The pilot who had first command failed to recognize impending stall and refused to let go of the side stick. Without valuable airspeed, the aircraft lost lift and plummeted into the black ocean with three confused pilots and a whole lot of lives on board.

After the series of investigations came to a close, most experts today agree that it was a systems failure. A failure that began with international regulatory bodies not mandating a proper training rigor which commercial airplane pilots required to act in the face of rare but dangerous circumstances. A failure that involved a sensitive cockpit control stick issue that is unique to Airbus, explained here very well by Capt.Sully Sullenberger. Mixed with the cocktail of other occurances such as bad weather and instrument malfunction, it was the perfect storm for an accident.

The crash of the Concorde 4590 was another systems failure as well. The ground level entities failed to clear the runway off sharp metal debris which had the potential to do harm. Flight's tires runs over said debris leading to a violent tire disintegration. Tire impacts the fuel cell. Fuel cell ruptures and throws fuel into two engine intakes subsequently leading to stall and flameout. Fuel ignites, starts a fire and renders two engines useless. This leads quickly to violent loss of life and property.

Finally, one more quick example from the much celebrated "Cactus" 1549 landing in the New York's Hudson River. What everyone knows by now (hopefully) is that the plane hit a flock of Canadian geese at around 2800 ft, leading to both engines losing thrust and a decisive moment from the captain to land in the river.

However, a Congressional Hearing after the incident saw Florida Republican making statements about old and inadequate number of Air Traffic Control routes to get planes out of La Guardia, a complaint of radar screen settings to "dumb down" clutter which may make it possible to block out information, such as a flock of birds. There were even remarks about the possibility of an inexperienced and unqualified Air Traffic Controller making decisions for routes in the absence of more experienced personnel.

Can you always control the flight path of Geese so they don't hit your plane? No. But if take off routes from the runway are inflexible and you combine that with the lack of information management, that can be a problem which could lead to a safety issue later down the line. This highlights a systems challenge.


Review Design Redundancy 

Aircrafts are basically complex computers into which redundancies are built. But does that answer for safety every time? A million times probably yes. One or two times, possibly no. But how do you try to widen the Yes-No probability divide so you know that you're operating in safe region for almost all of the time?

That's where a second eye on your systems design helps.

Consider the example of the F-16 air combat fighter developed in the mid-1970's by General Dynamics. At the time, it was state of the art in fighter jets, incorporating the first "fly-by-wire" mode of operation, which means any or all of the mechanical cables that moves flight control surfaces were replaced by servoactuators controlled by electrical signals.

The F-16 development engineers designed quadruply-redundant signals to each servoactuator, the reasoning being that the probability of losing all four electrical signals all at once was extremely remote and that no single-point failure condition could induce this condition.

Well, it turns out that after the design exercise, General Dynamics called together a separate group of engineers to analyze this design. This team found out that although the F-16 included quadruply-redundancy, should any of the common electrical connector plugs that these signals used fail or should the harnesses carrying the signals be cut, all signal paths would be lost. The development engineers had missed that one.

Was it a significant increase in cost to go back to the drawing board and correct that design? Yes. But it didn't cost as much as a life.

In the late 1980's, Boeing decided to do away with a heavy and obtrusively large pair of plug type 9ft x 9ft cargo doors on the starboard side of the 747 jumbo jet's belly. The original thinking of this design was that since the plug doors open inwards and wedge into the passageway, it would be an extra measure of safety against the possibility of breaching the integrity of the fuselage while the aircraft was pressurized.


But it was heavy and it had wide tracks. The new design would be a lighter weight gull wing design, that is, they would swing out and up.

To make it function, they built into it three rotary actuators and a complex system of aluminum C-shaped latches to allow the door to open/close and lock. An operator could depress the close button and have the door shut in about 15 seconds. Manually depressing the latch lock handle in the middle of door would be the final step in locking it. This final step would also isolate the opening/closing control circuits from electricity. Should the motors malfunction, a worker could manually operate the latching mechanism using a socket drive.

I obtained the locking sequence from a video released by FAA and it is shown below.


Sequence of events in the opening of 811's cargo door

Unfortunately, trouble brewed after the design was put into operational flight. A number of warnings of failing or improperly functioning door systems did not prevent the tragedy that was to come on February 24, 1989. Around 2:00 A.M on what was a routine flight by United Airlines 811 from Hawaii, a thunderous boom shot 11 million pounds of pressurized cabin air past a gaping 13ft x 15ft hole in the fuselage. In the blink of an eye, nine passengers were sucked out to their deaths.

The plane was heroically landed by the pilot. A larger disaster was averted but finger pointing took place soon, directing blame at 14 separate instances of manual door operation by technicians which investigators theorized could have damaged the door locks on this particular aircraft.

The actual clues to what happened lay not just at the bottom of the Pacific Ocean.

After recovering the blown out door, investigators were alerted to a well timed incident at Kennedy International Airport in June 1991. It was discovered that just after initial door closure in a 747-200, a stray electrical signal was able to rotate the cargo door latch open and move the 800 pound door up! This corresponded exactly with observations from the recovered cargo door which showed that the latch cams were moved to their open positions and this had thereby deformed the C shaped aluminum latches which would otherwise try and stop the cams from rotating.


Aftermath of United 811 rapid decompression

The door was a complex electromechanical setup and the weakest link was the faulty electrical wiring which permitted stray signals to actuate the door in flight. Within this design system was the larger system scope of all maintenance personnel who operated on it day in and day out and expected their actions to be safe. When a few warnings related to those doors arose in the late 80's, all the OEM could do was to criticize the ground operators rather than pinning down where the stray signal came from.

Trying to design for all possible things that could go wrong is an exercise in futility. Anything more expensive than it needs to be won't sell.  But aviation's strategy of building in redundancies has worked out well for a number of years.

Design is rarely held in a vacuum. An engineer would do well to appreciate a system's level view of design and recognize that all the paperwork, documentation, procedures, its eventual use, intended or unintended and the complex Information Management System that manages it go with that design.

Numerous air safety incidents have given hard lessons that has changed the industry forever. Though these tragic accidents are rare, the consequences are very damaging. However, reviewing initial designs with well formed evaluation criteria and implementing any subsequent lessons learned into future designs can continue to make aviation safer.

Let us hope the very best for all families and people connected to Flight MH370.

Friday, February 7, 2014

Possibilities in Automobile Hacking


Image courtesy : Koscher, Checkoway et al

Last month, I sat among a crowd of about a hundred at the Dubai Silicon Oasis HQ listening intently to a technical presentation from Audi Middle East on the technologies that go into their cars. Though the presentation had much more of a marketing component to it than the engineering type technical, you immediately got a sense of how dramatically Audi is transforming the car as we know it into a near autonomous system that augments the driver's limited capabilities.

Then I managed to get up and ask the presenter a question : "Does Audi really believe that more systems automation is the way to go in this age of vulnerabilities?" I didn't get a clear answer, and I think he replied something to the effect of 'we have been testing this extensively, it is reliable, safe' yada yada.

Car manufacturers have enough technology in the books to be able to clutch the control from you if you slept over your wheel and shifted lanes by accident. or to monitor the full 360 degree spectrum around your car ultrasonically to regulate vehicular distances, or to auto-pilot a parking maneuver into a very tiny space without you ever having to be present inside. Some technologies are deemed too immature to release yet, but manufacturers have already done a chunk of the thinking work. Implementation could be a few years away.

 How Stuff Works : Car Electronics
Last year, while traveling on an interstate trip across the eastern United States, I wondered what the car I
was driving would be doing deep inside it without my knowledge. I imagined the millions of lines of software routines flickering as they ran, hundreds of packets of information being driven on information highways from one control unit to another, the systems watching with precision every sensor on the car and taking in information to decide what to do. Wheel speed, steering angle, in-cabin temperature, door locks, air bags, lights, tire pressure, radio volume, exhaust temperatures....nothing was not known.

The longest trip I ever made in those days was a 10 hour straight slog with one rest stop. I'm not boasting about it. It came out of necessity to get to a certain place quickly. It tested the very core of endurance of my mind and with some hesitation I must admit I closed my eyes momentarily on more than a few occasions only to wake up with a split second bang realizing that I'm still in control of a 3000 pound vehicle moving at 70 mph.

This is the American way for hundreds of people and making use of the vast road networks to drive from one state to the other is a matter of pride and heritage. Flying is objectionable to many, even if it sounds an odd idea to be hauling your disheveled self from one time zone to the other surviving on highway Burger King. I can't blame them as a foreigner. You actually tend to like having this libery to travel far and wide and if you will allow me, its probably the most enjoyable way to see America.

Some select few have a job to do a trip across the entire continent in 5-10 days. They are called truck drivers and they haul hundreds of millions of dollars worth of cargo to make the Walmarts and Office Depots work. When diesel fuel picks up its pump price, guess who gets hurt most? Yes, its that fleet of semi trucks who are helping fire up the economy indirectly.

Back to the episode when I shut my eyes while driving. Boy, did those instances frighten me that I had to stop and get coffee. Sitting in a 24 hour Dunkin Donuts at midnight sipping the damn drug and looking at my watch, I invited possibilities that this wheeled machine should be automatically controlled from time to time. Or maybe all the time while I could catch the Z.

Sounds like a far fetched idea but OEM's know what I've already been thinking, except they started the thinking decades back.

But every good story needs a villian and drumroll, then came along the hackers. We owe it to these guys for making a mockery out of systems and exposing their security flaws. There is hardly any sarcasm here because if hackers didn't do what they did, perhaps I wouldn't be sitting with the 11th step in evolution of the Windows operating system. I could have the most secure piece of software there ever was, or I could be wrong. I'll wait till I get hacked.

However, unlike computer operating systems which have matured over several decades, vehicles do not apparently have a parallel idea of access control rights in their CAN protocol. Or they don't implement the full spirit of the automotive standards. I was surprised to glean this information while going through paper on the security analysis of a modern automobile.

The authors of the said paper manage to experimentally verify that anybody could reflash, i.e load a piece of potentially malicious code into a car's telematics unit without the need for authenticating! They also showed how it was possible to drive a car on an airport runway at 40mph and do various things to it remotely while it was moving, like killing the engine or preventing the brakes from activating regardless of foot pressure on the pedals.  Fewer than 200 lines of code added to their software, which they creatively named CarShark, could activate a door lock sequence and kill the engine.

It may sound scary. To me, it sounds like a fantastic theme for a short sci-fi story.

This occurred to me while I was driving to work. I imagined the plight of a private detective in a bustling metropolis bulging with traffic on the primary arterial road connection who had to sit waiting in his car on most days for hours in slow moving traffic...until one day he asks himself why on earth are these accidents happening on very select times, i.e rush hour. He decides to investigate.

He had heard various things that the cities coffers were drying up, the metro line wasn't making money, tourism had gone down and a new wireless toll system was announced by the state department. Connected? Sure.

Through a maze of cover ups and paper trails, he discovers that an unknown branch of the city's huge police department had an interesting tie-up with a technology startup known for industrial automation who as it turns out operated under a strange name purportedly selling softdrinks. Together, they entered into a undercover program wherein ordinary looking cars on the roadway would be wirelessly made to crash timing it flawlessly with the peak rush hour. The accordion effect would extend many kilometers down causing a traffic jam and while everyone stood still in their spots until the roadway cleared, the city made thousands from the automated toll gate.

Wishful as it sounds, you don't need a lot of money to do this as we learn that Spanish hackers manage to do such things on a car with just $20 dollars worth of parts. Gulp hard.

It is a given that the development of any technology must harbor a strategic element about what to do when that piece of technology is made to act in off-design conditions. Could it damage property? Could it injure, maim or kill someone?

Given that computers are an all pervasive phenomenon whether it be a watch or a washing machines, whether they are at home, in your cars, in a chemical refinery or a nuclear power plant, unscrupulous elements will tirelessly work at taking advantage of loopholes to disrupt its function.  Let's appreciate the time and costs of developing and testing such systems to perform in the most safe way possible. 

Thursday, August 8, 2013

"Keep It Simple Stupid" Is Not Simple

For as many people I have met and worked with in my engineering career so far, I must have probably heard a third of them refer to the term "Keep it Simple Stupid", or "KISS" principle for short. The idea is that when you're thinking of a new product or process, envision the most simplest ways of execution first. It helps make understanding easier, designs easier, it probably minimizes the cost function as well. [Right : The electromechanics inside of a passenger jet engine]

I hold that the more simple a solution gets, the more time that is required to think all potential system issues through, especially if you're in an industry where failure means loss of money, life or property. It would probably be a good exercise to inspect the history books and see who signed off on a "simple idea" that later came to mean the loss of his or her job and shame to the organization.

Sure, extra features have extra complexity and this is why people shy away from number of parts. Even in the electronic world, the rule of two's apply. Consider a binary system that has two 2 elements - on or off. The number of potential states is 4. But if you have 3 elements, the number of potential states are 64, not 8 as some many imagine! Since failures often like to happen at interfaces, you may imagine what the possibilities are for potential failures if a system had 10 elements and all states were relevant. Its daunting that a quick calculation shows number of states being exactly.... 1.23794e+27!

Having worked in the turbocharging world, I quickly absorbed that this principle has another side to the coin. Automotive turbo manufacturers like to keep their trade secrets, especially when it comes to the technicalities of aerodynamic enhancements on the compressor maps. Fortunately, the mechanisms of varying nozzle area to manipulate expansion ratios were not so erudite.

Honeywell's VNT turbos used a handful of movable vanes whose angles were actuated electrohydraulically by proportional solenoid, as this animation here shows. Within turbo circles, people called that complicated.  Cummins Turbo Technologies had patented a moving vane wall and fixed shroud design to do the same thing, this vane wall actuated by an electronic actuator via a series of gear reductions and linkages. Interestingly, another private turbo guy whom I had the pleasure to talk with had accomplished nearly the same function simply by applying a swing valve in his turbine housing which was then actuated electronically.

In the end, which design would you say was more simpler?

If you look at it from a mechanical point of view, you might say the switchblade in the turbine housing design. Looks simple from the outset, right? Well, it actually depends on the system variables you chose when you considered your system design.

One manufacturer who currently has variable geometry turbos in their portfolio kept mechanical movement simple in the interest of cost. In the validation stages however, they had more than a headaches to face. Field units were coming back with foreign object damage on their vanes which interfered with vane movement, oil leakages arising from improper assembly processes that polluted the unit and curiously, a case of intermittent interference issues between vane and shroud that required frantic brainstorming to minimize customer dissatisfaction. The latter as it turned out was a systems latency issue that the mechanical department had little grasp of.

The reality check here is that, you need one eye on reality at all times. Keep it simple stupid is not always simple as you think. If you design something really simple and fail to take account of all the system interactions that can make or break the design, you've not made anything simple, infact the outcome might spell trouble in the future.

 "Simple" could also require more development and testing time.

A case in point where that applies is in the graph below which shows that the number of development flights to validate a surface launched missile in the 1970's had an interestingly linear and inverse relationship with cost. Apparently, complex systems require little testing. They require most cost to validate, sure, but this upfront development cost might just mean lower life cycle costs in the long run. It has been said that the space shuttle, a 3 billion dollar vehicle with hundreds of systems, required fewer than five development flights.


I recall a funny incident during the course of my undergrad years when we were designing an off-road buggy for intercollegiate competition. The final chain drive from jackshaft to the rear axle was a full 22 inches in linear distance center to center. To transfer this 10 horsepower, a bombproof motorcycle chain was selected with 1/2 in. pitch.

We quickly realized the law of transference of energy in failures - one hard component will transfer its wrath to a weaker element which will then fail in graceless fashion  Hence, this heavy chain drive needed a tensioner or it would chew away at the steel sprockets during sudden load transients and stall our car.

We brainstormed with ferocious intensity and came up with multiple solutions. When it was crunch time and we had a just a few more days to complete build, one team member proposed a "simple" idea to prevent modification of the chainguard itself. He evangelized a flexible polymer idler sprocket that would sit in between the tight and slack sections of the drive which would rotate with chain movement and be completely encased within the existing chainguard.

It was simple and cheap. And what the heck, it looked great on the company website where the product was shown running on a chain in a stationary drive application.  It should have worked in our application as well right?

Not quite. Soon after we bought this $35 item and installed it, it had teething problems and it wasn't long before one of us would open the chainguard to find the worn out tensioner lying loose inside the case. The engineer in this case had misapplied a product that worked well on a stationary industrial application. However, its softness and compliance were completely ill-suited for a moving application where shock loads and transients of chain operation were in effect.

The funny part of this story is that as Murphy's Law would dictate, we would stall our car this way for the first time precisely on the day of competition at site. In the end, we ended up fabricating a more rigid tensioner out of steel which held plastic idler wheels to push down on the chain. We also changed our guard design to accommodate this setup. That extra machining time and modification might have cost us more, since in the real world, you have to hire a fabricator and his skills to do the work for you.  And that is the dilemma of a systems engineer. To reduce risk and keep the same performance, you need to increase cost.

So as we have it, KISS is not so simple to implement. As our regulatory world of engineering gets more and more stringent with durability, safety and environmental issues, engineers must let go of the burning torch of simplicity and learn to embrace complexity especially in light of the industry they are designing for. What are your experiences on this topic? Please leave a comment.