|Email not displaying correctly? View it in your browser.|
|President’s Point of View|
Absolute Zero- the Point Where all Molecular Motion Ceases
I think that Baltimore City may have hit a record low temperature sometime after midnight on February 20, 2015. Sometime during the early hours, I noticed 1.1 degrees Fahrenheit was displayed on an outdoor thermometer. I took that moment to reflect on my decision in 1996 to buy a house with hot water heat instead of the then popular heat pumps. Was it a decision based on weighing performance, life cycle costs and reliability? Roughly speaking, yes. I moved here in 1995 after living 25 years in temperate California. My first thoughts upon arrival in MD focused on East Coast winters and how to cope with them. Having originally grown up in the storm center of Northwestern Pennsylvania just south of Lake Erie, I knew something about the essentials necessary for comfort and durability in winter weather. I summarized these as hot water heat and a slate roof. The heat part of the equation involved recognizing the extreme performance range of boilers while the roof was a life cycle cost exercise with an unambiguous result.
As if to remind me during my first year in MD, the winter storm of 1996 found me suddenly confined to a Crofton townhouse coaxing the ice buildup off the fan entrance of a heat pump. Some of these resistance heater augmented pumps don’t work well in extreme conditions and may stop entirely when the airflow path ices up. Some neighbors also found their pipes frozen and, in general, the designs of Crofton town houses did not seem to meet the performance range required for the low temperature conditions that year. This year, the stories will go on. Cars did not start, pipes froze, and heating systems failed, caught fire, or provided inadequate heat.
On the roof side of my evaluation, I would observe that the standard asphalt roof is transferred to the landfill on average every 15 years. Compare that to my slate roof that is approaching 90 years in service and has no life limit other than the potential for physical damage from falling tree limbs.
As engineers and systems thinkers, we probably have an advantage over many consumers in meeting our own housing requirements. Although we cannot master all the technology and wisdom needed to deal with every issue, we can take advantage of building codes and their imbedded national and international standards. How deep, for instance, does the code require a water pipe to be buried in the ground? What BTU output is required for a furnace to maintain a guaranteed temperature in a given structure at a specified outside temperature? Applying standards, we can determine that when heating systems fail to perform in extreme conditions, either the standards are inadequate, the system non-compliant, or the system has been rendered non-compliant by unapproved modifications.
I look forward to leaving the extreme cold and its challenges behind us as we move into March. Our February 18, membership meeting was disappointing due to the cancellation of our speaker David Scheidt, JHUAPL, due to an injury sustained while operating a drone earlier that day. In place of David’s presentation, we substituted a program featuring a video of the late Dr. Eberhardt Rechtin speaking on Systems Architecting of Organizations. David has agreed to reschedule for a future meeting. We also moved the Officer Installation ceremony forward due to the early departure of members trying to beat the onset of a new snowstorm.
Next month, we will announce our scheduled monthly speakers, tutorials, and training classes. Temperatures will rise and at that point our molecular motion should pick up!
18 March, 2015 (6:00pm – 8:00pm): SE Considerations for Applying Model Based Systems Engineering (MBSE)
Presentation: This presentation discusses key topics that must be accurately and completely developed during the initial stages of a system development when applying Model Based Systems Engineering (MBSE). The key topics addressed are: Stakeholder Needs Analysis, System Use Cases, Scenarios, Sequence Diagrams, Systems Modeling Language (SysML), and Architecture & Modeling and Requirements. The use of the term “Initial Stages” refers to the activities in the upper left of the Systems Engineering V diagram where it is essential to develop and understand Stakeholder Needs and to translate these into well-defined Stakeholder and systems engineering products including architecture views/models. The architecture views refer primarily to the SysML diagrams but Use Cases and Sequence Diagrams are also necessary parts of the development process.
Go to www.incose-cc.org/registration/ to register
Parsons Auditorium, Bldg 1
Modeling the Mechanical Watch using The Department of Defense Architecture Framework (DoDAF)
by George Anderson
Domestic watch manufacture in the United States ended in 1969 when the Hamilton Watch Company of Lancaster, Pennsylvania ceased production. This ended an era that spanned at least 100 years. While the company is still in existence, all its watches are now produced outside of the United States. Hamilton’s contribution to the precision, quality and beauty of the mechanical watch is represented in the last of its railroad watches, the model 992B, shown in Figure 1. Some have said that the quality seen in the 992B and its contemporaries was so remarkable that today’s counterfeiters of antiques cannot economically duplicate it.
Today, many take timekeeping for granted to the extent that some are even abandoning the use of a personal watch to use the time function on their cell phone. For others there is a fascination with the mechanical watch or its heritage that supports a robust market in expensive watch lines such as Rolex, Omega, and even Hamilton. These watches can sell for prices in excess of $6000 even though the cheaper quartz watch is a superior timekeeper.
Since the mechanical watch is not going away in the near future, an abbreviated Systems Engineering model may provide some insight into the physical concepts involved and identify the common principles that the mechanical watch shares with later technology, including the Cesium clocks that are used in the United States Global Positioning (System GPS).
We will use the Department of Defense Architecture Framework (DoDAF) for our model since its guidance is readily available on the Internet. The model’s description claims that its views should be selected on a “fit for purpose” basis so only three will be used to model the mechanical watch.
DoDAF views aspire to describe a defined aspect of an underlying model that contains more comprehensive information about the actual system. For this effort we will be content to provide only the data shown in the selected views. Our underlying model if pursued fully would contain a great deal of the information accumulated in over 100 years of engineering improvements. Watch collectors and horologists have available considerable amounts of technical information on mechanical watches ranging from such issues as lubrication of jewels to the development of advanced metal alloys for hairsprings.
The DoDAF, Operational view, OV-2, shown in Figure 3, illustrates the major activities performed by the watch and the resource flows between them. There are only two resource flows: energy and time transfer that together support the activities. The activities in turn provide an independent time reference and display an output by moving clock hands.
The DoDAF, OV-5b, Figure 4, shows the same resource flows as the OV-2 and adds two important external interfaces that service the watch by periodically winding up the watch mainspring and setting the time to an external standard.
Figure 5 shows the DoDAF, Systems View, SV-1 that depicts system modules decomposed into component parts. Note that the wheel (gear) train serves a dual purpose. It both transmits power and communicates information from the Balance Wheel to the Time Display.
After studying the three DoDAF views, we can visualize the individual watch systems’ purposes and relationships but have no information on the physical implementation. To understand fully how the watch functions we should view the motions of the balance wheel, escape wheel and the connecting pallet lever. A link is provided here: Watch Animation. Alternately, we can study the exploded views in Figures 6 & 7.
It is important to note that this design is common to the majority of all watches manufactured in at least the last 100 years. Any variations are extensions to the design as opposed to basic changes. An example of an extension would be the self winding watch wherein an internal pendulous weight instead of the watch owner winds the mainspring.
The DoDAF views contain enough information to describe what the watch does and the systems involved. It does not provide information on the mechanical principals of operation or the nature of the communications between systems. In the mechanical watch, gear trains are the means of both transmitting power and communicating the passage of time. A key system feature that is common with all timekeeping devices is the Time Calculator. In practice this is always a form of oscillator that supplies a constant periodic motion or electrical signal. The mechanical oscillator, a balance wheel, has been supplanted with miniature quartz tuning forks (the quartz watch) as well as more advanced concepts that include counting the vibrations of atoms. Quartz watches are at least 5 times more accurate than a mechanical watch but fall short of the accuracy provided by Cesium Clocks. Cesium Clocks cannot be worn on the wrist but anyone carrying a smart phone with GPS installed has access to their output and essentially requires it to provide an accurate geographic location.
Will the mechanical clock as we know it today continue to be developed? The answer is probably yes for at least two reasons. The first reason is that the technology is based on years of design evolution that is well understood and has applications in other industries such as microelectronics. Second, there is always a need in special environments for independent time keeping devices that do not use electrical energy, can be made immune to remote tampering, and may be produced cheaply in large quantities.
Did the DoDAF architecture views aid in gaining an initial appreciation of the major elements and functions of the watch? If not, perhaps there is a latent curiosity to go beyond the Systems Engineering element and delve more into what can prove to be fascinating details. What for instance are the two functions of watch jewels or the purpose of using solid gold wheels in the gear train. If these questions captivate you, the following web sites are worth viewing.
How a mechanical watch works:
Hamilton How a watch works
What makes a fine watch fine
The Elgin Watch Factory
The final question to present before concluding is: Did the DodAF model efficiently describe enough of the watch design to be a useful exercise? Here we have the elemental challenge of all engineering models – does the effort justify its creation. I believe that in the case of the mechanical watch it does in the sense that it can be an enticing entry into the study of more technical details that would otherwise be avoided or ignored. After all, spending $6000 or more for a watch could justify a little investigation.
Keep It Simple?
by Zane Scott
“For every complex problem there is an answer that is clear, simple, and wrong.” H. L. Mencken
“Everything should be as simple as possible, but not simpler.” – Albert Einstein
Sage advice from two well-known minds. What does this mean for us in the model-based systems engineering world?
Mencken reminds us of the lovely trap of leaping to a conclusion that seems to be attractive at first blush but can lead to problems down the road. This is the result of an incomplete consideration of the problem and the alternative solutions. We look at a potential solution which seems clear and simple and are attracted to it. After all, this would “solve” our problem in a straightforward way. It would be relatively easy to implement and easily understood by stakeholders.
Often we couple this with the danger against which Einstein warns us. We can either deal with problems in all their complexity or we trim away the complexity and treat them as if they were actually simple. The latter is a tempting choice. It is sometimes accomplished by breaking the problem into simple “sub-problems” with which we deal separately. This is a product of our analytic training and mindset. We are taught to understand systems (and problems) by breaking them apart into their components and tackling each one in turn.
The problem with this approach is that often the challenge of a complex question comes precisely from its structure- from the relationships between the components that make it up. When we deconstruct the problem we lose this complexity from our thought process. We induce the “excessive simplicity” against which Einstein warns us.
If we over simplify the problem and couple that with a rush to a simple solution we under consider both the problem and its alternative solutions. That can result in unintended consequences stemming from our solution or a solution that just simply doesn’t work. Neither of these is sufficient as an answer to the problem. The consequences of both Mencken’s and Einstein’s caveats are visited upon the solution.
How do we avoid those traps? The answer lies in a robust, disciplined problem solving process leading to an effective solution.
The process must be robust. It must be capable of handling the complete problem. We need insight into the actual problem that includes all the aspects of the problem and its impact. Our model must give us insight into the actual problem and its setting in order to provide us with a way to judge the alternative solutions against reality instead of some simplified straw man. The expression of the problem and potential solutions in all domains (requirements, functional behavior, physical architecture and verification and validation) should be handled together holding them in appropriate relationship to each other to promote our insight and understanding. All this requires a robust modeling tool capable of handling the data around a complex system.
The process must also be disciplined. It should allow consideration of all reasonable alternatives. The discipline or “rigor” of the problem solving process is what leads to an assurance that all the bases have been touched. By following a disciplined path we can track all the relevant considerations into our solution. We find that beginning at a very high level with our problem description and with our solution allows us to add more and more detail or granularity in an organized manner. This prevents the omission of critical aspects of the problem or potential system solutions. In this way we can examine all the options and make an informed set of design choices.
We avoid the impulsive oversimplification against which Mencken cautions through a robust process. No matter how complex the reality of the problem/solution space we can accommodate the system in our model. We consider all the domains together without needing to fragment or ignore them. We can arrive at the “right” solution.
With a disciplined process we can simplify the problem and the solution in relevant intentional ways. Our approach takes us through the right considerations so that we can see the system around the problem as an interrelated whole. We can then trim away the unnecessary and irrelevant in an intentional rather than arbitrary way. As Einstein advises we can then work on problems and solutions that are as simple as possible and no simpler.
Through our robust and disciplined processes we can arrive at the right answers to clearly defined real world problems.
© Vitech Corporation 2015, Reprinted by Permission
Volunteers Needed to Judge at High School Science & Engineering Fairs
Again, we want to represent INCOSE at local High School Science and Engineering fairs and seek volunteers to help judge selected student projects. For those who have done this, are always amazed and pleased at the variety and sophistication of what some students do. This is an opportunity for us to provide guidance and advice.
The following fairs are scheduled for March:
Usually over 200 projects are available. A team of 2-3 usually cover around 10 projects in time period allotted; so we will preview and preselect projects of interest usually in categories of Engineering [electrical, mechanical], Computer Science, Math & Physics, Transportation, Energy, Environmental, Health Sciences, etc.
Award ceremony takes place on a later date and any/all can attend.
Please contact Don Gantzer, Outreach Lead, 410-956-1562, email@example.com for more details.
Upcoming Events and Announcements
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.
The Chesapeake Chapter is always looking for volunteers to speak at our upcoming meetings! Please contact our 2015 Programs Director, Glenn Townson, if you would like the opportunity to speak or can recommend someone.
The Chesapeake Chapter of INCOSE is proud to recognize the following organizations for sponsoring our endeavours to expanding the understanding and appreciation of Systems Engineering in the local area:
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.
Please use the Forward email link below so we can invite your friends to join our mailing list. Thanks in advance.
INCOSE Chesapeake Chapter © 2015