Systems Engineering

Fifty Lessons Learned

Howard Eisner

• Éditeur: CRC Press
• Année: 2020
• ISBN:
  9781000165852
• Édition: 1
• Sujet: Technology & Engineering
• Sous-sujet: Industrial Engineering

The author has spent approximately 50 years in the field of systems engineering. This Focus book provides a "looking back" at his 50-year run and the lessons he learned and would like to share with other engineers, so they can use these lessons in their day-to-day work in systems engineering and related fields.

The book is written from a systems engineering perspective. It offers 50 lessons learned working for a variety of different companies, which can be used across many other engineering fields.

The book will be of interested to students and engineers across many fields, as well as students and engineers working in business and management fields.

1
Technical

1. When and Where Possible, Go Back to Fundamentals (*)

So what, indeed, are the fundamentals? In a nutshell, they’re basic physics and engineering. I would like to illustrate this with a few stories.

Case One

I was having dinner with my son and his two twin sons, my grandchildren. We were exploring entrepreneurship, and what it might take to become one. To make a point, I suggested that there might be a huge market for a device that un-cooks a steak (or the like) when it is well-done rather than rare, as the customer requested. After all, with such a device, restaurants could save huge amounts of money.

“That’s a great idea, grandpa”, they both agreed. “Let’s build such a device”.

I encouraged this whole adventure, and they went off with a happy assignment – to figure out how to build a steak un-cooker. Their enthusiasm was almost boundless. If successful, they would become super entrepreneurs – at age 20.

A few days later I got a phone call from one of these grandchildren.

“Grandpa, I have bad news”, he said

I replied, “Don’t keep me in suspense. What is it?”

“I’m afraid that we can’t build a steak un-cooker. It violates the Second Law of Thermodynamics! We discovered that by going back to our High School physics class notes and our textbook”.

“Terrific”, I said. “You did what needed to be done. You both went back to some fundamentals”.

And so the tale ended.

Case Two

Another story goes like this. It was suggested by a friend of mine that I visit with an ex-Israeli who lived in Queens, New York. So when I was spending some time with my brother in the Big City, I went with my sister-in-law to see this ex-Israeli. He showed me an “invention” of his, a prism that took in light and produced the colors of the spectrum as an output.

“There’s more energy coming out than the energy going in”, he said, spinning the prism around in his hand. “How about we develop this together, and make a fortune”, he suggested. With that, he thrust a paper in front of me and urged me to sign it. It was a partnership agreement that, presumably, would get us up and running.

“More energy out than the input energy”, I thought. “That simply cannot be. That’s more than 100 percent efficiency, and violates a basic Law of Physics”.

My sister-in-law, also an ex-Israeli, spoke to him in Hebrew and then to me in English.

“This is a scam”, she said, under her breath. “Don’t fall for it. He just wants an open pipeline to your money”.

I had come to the same conclusion, more-or-less at the same time.

“Sorry”, I said, “but I’m going to have to decline your offer, and we have to leave now”. And with that, we left his premises and drove back to my brother and sister-in-law’s apartment.

There are times, I thought, when one just needs to go back to fundamentals, which also might help in avoiding a poorly disguised scam.

Case Three

I was a young engineer in my 20s and was watching and listening to a senior engineer (actually a physicist) explain his thinking in solving a difficult problem. He did so with grace and a complete command of physics. He set forth a very convincing argument as to how he derived a certain formula and what the “answer” was very likely to look like. I watched and listened in great awe.

“This is what research is all about”, I thought, considering his “heuristic” as both correct and masterful.

So there we have it. Three cases that help to illustrate the premise. They’re all different, but they demonstrate the point. Stay with the fundamentals, and make sure to be careful as you do so. In particular, listen and don’t sign any partnership papers.

2. Seriously Explore Alternatives, Even If Time Is Short

This admonition is one of the author’s favorites and receives a fully intentioned asterisk [1]. A key issue for the system architect is to take the time to define and evaluate alternatives. The “analysis of alternatives” (AoA) was suggested by the Department of Defense (DoD) as an important part of building new systems. It’s not clear as to when and if the DoD will enforce this suggestion; it would be surprising if they did not.

The Department of Homeland Security (DHS) has also explored the notion of analysis of alternatives and has documented their approach [2]. Some of the features of this approach are delineated below:

• First, the alternatives need to be defined
• Then one identifies operational scenarios and concepts of operations (CONOPS)
• This is followed by setting forth effectiveness measures for the alternatives
• Which leads to estimates of cost
• One then plots the values of cost and effectiveness on a graph
• Then this graph is analyzed, in detail

So we see above a basic cost-effectiveness approach. The alternative that is most cost-effective is usually selected unless there are other over-riding factors and influences in play.

Examples of problem areas that are subject to the definition of alternatives include:

1. 1. Buying an automobile,
2. 2. Buying a house, and
3. 3. Buying a computer.

But first we look at a short tale from the world of military communications. Some years ago, I had the pleasure of working on a system known as Consolidated Space Operations Center (CSOC) on a sub-contract for the Air Force. We had won the base contract and moved on to bid on the follow-on effort. In our proposal, we were faced with the matter of what our approach should be – frequency division multiplex (FDM) or time division multiplex (TDM). During the base year contract, we took the position that FDM was the preferred approach. This decision carried the day, and we therefore bid an FDM approach for the second phase contract. As it turned out, a competitive bid came in, taking a TDM approach. That competitor won the competition. As best I can remember, going with TDM was in line with a trend toward digital communications and its inherent compatibility with the computer and various off-the-shelf hardware and software. So we learned a lesson that day: in retrospect, it was conjectured that we should have submitted two bids – one for FDM and the other for TDM. So the wrinkle in the analysis of alternatives sometimes can be not “either-or”, but “and”. Sometimes it’s possible to bid more than one alternative, rather than just one.

While we are on the topic of bidding on contracts, we recognize that in such a scenario where time is usually short, there’s a lot of pressure to come up with an answer. So participants argue that there’s not enough time to look at more than one singular alternative. This, of course, is not an AoA case since there is only one selection. This author believes that this is generally wrong-headed and that just about all situations call for a legitimate AoA. If one does not do this, then a price is usually paid down the road.

We turn our attention now to the DoD and what their approach might be and how they look at the overall issue [3]. The stated objectives of an AoA, as repres...