Dinner Meeting – Wednesday 16 June 2010 Systems Engineering when the Stakes are High and Time is Short: Lessons from the Lunar Reconnaissance Orbiter David Everett, NASA
Presentation: Schedule pressure is common in the commercial world, where late delivery of a product means delayed income and loss of profit. Research spacecraft developed by the government, on the other hand, tend to be driven by the high cost of launch vehicles and the public scrutiny of failure–the primary driver is ensuring proper operation in space for a system that cannot be retrieved for repair. The Lunar Reconnaissance Orbiter (LRO) development faced both schedule pressure and high visibility. The team had to balance the strong push to meet a 2008 launch against the need to ensure that this first mission for Exploration succeeded. This presentation will provide an overview of the mission from concept through commissioning and explore some of the challenges the systems engineering team faced taking a mission from preliminary design review to pre-ship review in 3 years.
Speaker: David Everett has led the design, build, and launch of three spacecraft (FAST, WIRE, and LRO), and he was a key player during the launch of three others (SAMPEX, SWAS, and TRACE). His eighteen years at NASA has included substantial experience in the assembly and testing of spacecraft. Starting in September 2005, Mr. Everett led the technical effort for the Lunar Reconnaissance Orbiter (LRO) as the Mission Systems Engineer. Mr. Everett is currently the chief systems engineer for the Heliophysics and Explorers Program Office at Goddard. He earned a BSEE summa cum laude, at Virginia Tech in 1986 and a MSEE at the University of Maryland in 1989.
Meal: Taco nite — Soft flour tortillas and corn tortillas; Seasoned ground beef; Sour cream guacamole assorted salsas; Tomatoes, lettuce, etc; and Black Beans and Rice with garden salad dressing, rolls and butter, dessert, coffee and iced tea
Reservations: By website: Credit card via PayPal, go to our >>Events Page<< or By email: Contact Don York at email@example.com
For details on the presentation, more about the speaker, cost details, cancellations, and directions
Presentation ONLY: FREE (no reservations necessary)
The purpose of the Chesapeake Chapter is to foster the definition, understanding, and practice of world class systems engineering in industry, academia, and government. In light of that goal, every month at our dinner meeting we have a drawing for the latest in Systems Engineering literature. So come on out for a chance to win. This month’s door prize is: The Martian Principles for Successful Enterprise Systems: 20 Lessons Learned from NASAs Mars Exploration Rover Mission
by Ronald Mak
Get to Know … Our Programs Director: Mr. Don York
Dr. York has over 30 years of professional experience in the areas of Mechanical and Systems Engineering. He has been an active member of INCOSE since 1994 formerly serving as co-chair of the Requirements Management Working Group. He is a licensed professional engineer, a Certified Systems Engineering Professional and holds a PhD in Information Technology Systems Engineering from George Mason University. His doctoral thesis was entitled: An Early Indicator to Predict Requirements Volatility. Dr. York has taught systems engineering at the graduate level at both George Mason University and the University of Maryland Baltimore County. He is currently a senior systems engineer with TASC. Prior to joining TASC, Dr. York was engaged in the development, engineering and deployment of leading edge technologies and systems at Sage Management, AT&T Bell Laboratories, the Westinghouse Research and Development Center, and Northrop Grumman Corp.
Did You Miss Last Month? Lecture: Risk Profile for NASA’s Crew Exploration Vehicle
This presentation in depth lecture on developing a risk profile using the Delphi technique. The subject of the study was NASA’s Crew Exploration Vehicle (CEV) system concept. Working with Subject Matter Experts in various fields, Dr. Mahata and his team developed 14 very specific questions which covered the whole gamut of SE concerns. They found the Delphi technique was easy to apply and very cost effective.
If you missed it, not to worry — you can download his presentation >>HERE<<
Visit our Library section of our Website to also find other copies of presentation materials from previous meetings or other gatherings of interest. Poke around and see if anything looks interesting.
Feature Article #1 Systems Integration – Revisiting the Definition of an Old Friend by Donald M. York
What is Systems Integration? How does one define it? Sometimes, in order to understand what something is, we must first understand what it is not. Systems Integration is not a box drawn at the end of a life cycle that instructs us to put the system together. Systems Integration isn’t something a contractor puts on their business card to obtain consulting work. Systems Integration is not a point in the life cycle but a continuum. Systems Integration is not only concerned with the integration of hardware and software but of processes and specialties as well.
One of the goals of Systems Integration is to achieve customer satisfaction. The word integration is related in its root to other words such as integer and integral. These words speak of a “whole” not a part. Systems Integration, therefore, is related to the whole, throughout, and not just part of the system life cycle. One is integrating all of the specialties throughout the life cycle and not only at the end of the life cycle. Systems Integration is a synthesis. To integrate is to merge into a whole, to complete, to combine, to make harmonious or to orchestrate. Integration is a blending or a uniting.
Systems Integration is involved with the requirements as well as architecture. Integration of design requirements is part of the system engineering process. The rigor imposed by a formal systems engineering process ensures that all of the specialty disciplines respond to requirements in a timely and integrated manner. Systems Integration involves architecture also. One takes all of the pieces and puts them together somehow to yield a functioning system that accomplishes the requirements. Part of this “putting together involves interface definition and control early in the program for successful and on schedule development. This putting together is Systems Integration. Systems Integration is not only new development but COTS and re-engineering.
In attempting to understand Systems Integration, one can begin by first examining some definitions of Systems Engineering. One finds that the concept of Systems Integration is embedded as a component of these definitions of Systems Engineering. First, the old MIL-STD-499A defines systems engineering as:
The application of scientific and engineering efforts to (a) transform an operational need into a description of system performance parameters and a system configuration through the use of an iterative process of definition, synthesis, analysis, design, test, and evaluation; (b) integrate related technical parameters and ensure compatibility of all physical, functional, and program interfaces in a manner that optimizes the total system definition and design; (c) integrate reliability, maintainability, safety, survivability, human engineering, and other such factors into the total engineering effort to meet cost, schedule, supportability, and technical performance objectives.
The Defense Systems Management College defines systems engineering as follows:
“Systems engineering is the management function which controls the total system development effort for the purpose of achieving an optimum balance of all system elements. It is a process which transforms an operational need into a description of system parameters and integrates those parameters to optimize the overall system effectiveness.
The International Council on Systems Engineering (INCOSE) includes as part of their definition of Systems Engineering as integrating “all disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production.”
Although these are definitions of Systems Engineering, pieces of the definition contain references to Systems Integration. Extracting from these definitions, integration seems to contain the elements of compatibility, optimization, interface, totality and effectiveness. Systems Integration is what achieves optimization. According to MIL-STD-499A, systems integration ensures “the compatibility of all physical, functional, and program interfaces in a manner that optimizes the total system definition and design.” Both the MIL-STD-499A and INCOSE definitions speak, not only of product integration, but also of integrating disciplines into a total engineering effort. At a minimum, then, the aforementioned elements should be contained in a proposed definition of systems integration. Furthermore, one must answer the question, what is the end or goal of systems integration? In other words, why are we doing it? The answer is to satisfy the objectives or requirements levied on us, to meet cost and schedule objectives, and to optimize the effectiveness of our system. The elements of operating together and interfaces must be included in our definition of Systems Integration as well.
Therefore, borrowing some of the phraseology from the above stated definitions of systems engineering, my proposed definition of Systems Integration would be as follows:
Systems Integration is a process or a set of actions which ensures that the elements of a system are compatible and function together such as to satisfy the requirements, meet cost and schedule and optimize the effectiveness of the system. It ensures the compatibility of all physical, functional, and program interfaces in a manner that optimizes the total system definition and design. It amalgamates all disciplines and specialty groups (i.e., reliability, maintainability, safety, survivability, human engineering, and others) into a total engineering effort to meet cost, schedule, supportability, and technical performance objectives.
Feature Article #2 Exploring the Envelope by George Anderson
Anyone hanging around aircraft test pilots or watching movies about them doing daring things probably remembers hearing the statement: “We are exploring the envelope”. Alternately, if you recently read a Boeing plush piece for the new B-787 aircraft prototype, you may notice the statement: “we are extending the envelope.”
This pilot talk has an interesting instantiation in the world of the systems engineer and you may hear it used by persons who may or may not totally appreciate its original meaning. Before we consider the system engineering implications or the wisdom of adopting this phrase, we should briefly explain just exactly what it is the pilots are referring to. After all, they share a common compulsion with systems engineers to take complex situations and reduce them to two-dimensional charts and use these charts to make important decisions.
All air breathing aircraft have a range of speed capability that varies with altitude, fuel load, temperature, atmospheric pressure and power plant characteristics.
Simplified down to a two dimensional chart, the aircraft envelope can be drawn as a combination of two variables. On a Cartesian chart, the x-axis depicts the range of speeds and the y- axis covers the range of altitudes that the airplane can attain. The result of plotting all the combinations of speed and altitude results in a closed polygon shape that that bounds all the possible points that the aircraft can pass through in controlled flight. Figure 1. Presents a hypothetical aircraft performance envelope.
The vertically oriented minimum speed line on the left indicates where the aircraft wing stalls. The line to the right documents the maximum speed that can be safely reached without danger of structural failure. Note that the two lines converge as the operating altitude increases. The narrowing of the envelope can have serious implications for operating the aircraft at or near the highest altitude in the envelope.
This is because the range of speed between maximum and minimum is becoming so small that it is difficult to maintain the aircraft speed between the two limits. This is especially true when turbulence causes un-commanded airspeed variations. All pilots call this area on the chart, coffin corner. Smart pilots imprint these charts in their memory.
What then, does it mean to explore an aircraft’s envelope? A new aircraft is not born with an envelope ready for the pilot to use. Instead, the test pilot flies until he verifies the limits of safe flight. This is not a job that can be done safely without a lot of previous flight experience and a solid theoretical understanding of many subjects coupled with courage to face the unexpected.
Expanding the envelope on an aircraft can only suggest that fundamental changes are being made to the design that allow it to fly higher and/or expand the range of permissible airspeeds. Thus when Boeing says it is expanding the envelope of the B787 they are making yet another change to the design and lengthening the delivery dates to anxious customers. It could also mean that the recently completed test envelope is below par.
Other Systems have performance envelopes just like aircraft. Every system operates within boundaries defined by physical laws and a plot of this data can aid the system engineer in performing development activities. For instance, information systems represent a significant subset of all man-made systems and are defined by gross parameters such as bandwidth, delay, data integrity and so on. If two variables are selected carefully, the resulting test envelope will provide a valuable record of performance. For instance, plotting operating temperatures vs. input voltage variations can establish what environmental conditions are acceptable for routine operation.
The system engineer should define the initial equipment performance envelope and fully explore and document this envelope during testing. Following the deployment of the system, the envelope should be continuously monitored by instrumentation designed or adapted specifically for the purpose.
There are other types of data charts, but the concept of the performance envelope is very useful in almost every system and the systems engineer can make good use of this concept in presenting clear and actionable data to the end user’s maintenance and operations functions.
Exploring and extending the envelope is, indeed, a suitable exercise for the systems engineer and, in conclusion, I leave one question as an exercise for the reader.
Is there a man-made system that does not have continuously bounded performance limits.
A Word from our President POCDC, Writers Block and NASA Systems Engineering.
Welcome to our June newsletter. We have filled it with samples of the bounty from our last month’s activities and descriptions of upcoming events. We also have provided quirky little articles designed to appeal to the reader who enjoys getting brief and hopefully professional insights into whatever pops into the Board Members’ minds several days before the publishing deadline. It is my fondest wish that we will soon publish what you, the membership, are motivated to contribute in a spirit of sharing your latest insight or discovery. If you need help or assistance, members of the BOD will help you get in the submission queue and may even buy you lunch because for some reason there is occasionally a reported case of writer’s block. As President, I have ruled that writer’s block is not a recognized illness that can be used to deny our membership the ability to enjoy a few minutes of illumination, advice, or camaraderie from their elected and serving representatives. I firmly believe that routine and relevant contact with the membership is essential to furthering the Chapter’s goals. While I am President, I will insist that the leadership take the lead on this and I ask you the membership to reciprocate in a sense of professional cooperation.
Our last meeting continued the upward trend in attendance with 35 attendees applauding Dr. Paul Mahata’s presentation on NASA’s Crew Exploration Vehicle. To most members, the program arrangements are not visible. It is all so easy to take the program for granted until you realize that obtaining good programs is a long lead-time process. Our Program Director, Don York, is a seasoned master of the long-term give and take with the speakers and moving them into the speaking arena on the scheduled evening. Added to this, he has to negotiate and field requests from the membership. Much if not all the credit for our recent outstanding attendance is due to Don and the lonely work that he began in some cases two years before the event. Be sure and seek Don out and thank him for what you didn’t see at the presentation.
I began this piece with an acronym that I really am anxious to share with you.
I blurted it out during a recent ITIL training session in response to a similar Deming gem that seemed awkward in comparison. Checking afterward about the origins of these things, I learned that mine has a pedigree going well back into recorded history. POCDC stands for: Plan, Organize, Coordinate, Direct, and Control. The beauty of this little packet of wisdom is that it encompasses the what, and, in what order, guidance for almost all imaginable tasks. It works especially well with small groups who are attempting to work together without a lot of wasted effort and confusion. Who would guess that you would see a simple process like this reintroduced in a Systems Engineering newsletter? Try it soon.
This is the monthly newsletter for INCOSE Chesapeake, a local chapter of INCOSE International. We are a not-for-profit organization dedicated to providing a forum for professionals practicing the art and science of Systems Engineering in the Northern & Central Maryland & Southern Pennsylvania area.
Mark your Calendars:
Date: 21 July 2010 Presentation: Architecture Design, Simulation and Visualization Using SysML) Speaker: Gundars Osvalds
Date: 16 August 2010 Presentation: Experiences and Lessons Learned on the Quality Service Management Initiative Speaker: Carl W. Deputy, Northrop Grumman
The Chesapeake Chapter is always looking for volunteers to speak at our upcoming meetings! Please contact our Programs Director, Mr. Donald York, if you would like the opportunity to speak or can recommend someone.
What’s the lowdown on CSEP? The International Council on Systems Engineering has established a multi-level Professional Certification Program to provide a formal methodfor recognizing the knowledge and experience of systems engineers, regardless of where they may be in their career.
Read more details at the INCOSE Website.
UMBC Training Centers offers a CSEP Prep Course Dates: 4 Saturday Mornings,
July 10th — 31st Location: UMBC Training Centers @ 1450 S. Rolling Road, Baltimore, MD 21227
Discover Systems Engineering
Read the current issue free on-line for a limited time: Click Here
Copyright (c) 2010 Wiley Periodicals, Inc., A Wiley Company
As a member of INCOSE you have online Access to the current and past issues of The Journal of Systems Engineering via the Wiley InterScience site. Search the archives and download papers of interest. Registration on the Wiley site is required. Instructions for accessing the SE Journal can be found in INCOSE Connect
With Connect you can also download the latest April Issue of INSIGHT: Reflections on the Technical Engine of INCOSE
Clink on image above and Log-In today.
Our Chapter now has a presence on
Check it out and join our group so we can together discuss the latest in Systems Engineering news and events.
Did You Know: 1) You can earn PDUs by serving your local chapter
If you have a CSEP (or an ASEP) you can pursue activities in one or more of the three categories:
Technical Society Participation Category
SE Course Work and Publication Category
SE Job Function Participation Category
to earn the minimum of 120 PDUs required for recertification. Under the Technical Society Participation Category you can “Participate on Professional Technical Society working groups, committees, etc.” or “Perform Leadership Role in Professional Technical Society at local, national or international level” and earn 1 PDU/hour of effort. Best of all, there are no limits placed on the amount of PDUs you can earn this way.
Bottom line – Volunteer Today to help make the Chesapeake Chapter of INCOSE the best in the world.
2) You can catch a missed Webinar. Check out the most recent one on the CSEP program
All of them are archived in INCOSE Connect Products Area. Open the INCOSE Products folder and then open the Webinar Archives folder. Go to the very bottom and you’ll find the twentieth INCOSE webinar, held on 19 May 2010, where Dave Walden and Eileen Arnold gave a presentation on “INCOSE Professional Certification and the new Expert Systems Engineering Professional (ESEP) Designation”
This Newsletter is to serve our members and is open to all for contributions. Do you have an interesting idea for an article? A review of a new book related to engineering? Let us know. We’d love to hear about. It may wind up in a future issue of our Newsletter.
Keep up with the latest news and events. Find out about our new Board of Directors. Explore our extensive library of previous lectures from our Monthly Dinner Meetings. Learn of the Benefits of Joining INCOSE. Check out Systems Engineering education in the local area. All this and more awaits you at our INCOSE Chesapeake Chapter Website.