Systems Science and Systems Engineering
A. Wayne Wymore
Professor Emeritus of
Systems and Industrial Engineering
The
4301
wayne@sie.arizona.edu,
http://www.sie.arizona.edu/faculty/wymore.html
From the International Journal of General Systems, Vol. 33, No. 6, December 2004, pages 593-610.
This is not a history of systems
science nor of systems engineering; it is a very personal story about a career
exploring both these fields. No attempt is made to give a complete accounting
of all my experiences; only a few major events and epiphanies are recounted. I
begin with recollections of early influences. Then, I tell how, as a student at
A winter wind was swirling
around our house leaving snow in deep drifts. We were expecting my father and
two uncles to return from a remote section of
It was Parents’ night at
We were in a room in
After a summer of work on a
surveying crew subsequent to graduation from high school, I was standing in
line in Jefferson Barracks,
The plane we were on was landing
to refuel at
During my two year tour of duty,
I managed only to complete a course in trigonometry by mail. Trigonometry was
only one of many courses in mathematics and science that could not be offered
by the war-decimated faculty of
After discharge from the Army, I went back to Ames and, since I was qualified for the GI Bill of Rights and had no fixed goals in mind, I decided to try college and matriculated in Iowa State University (ISU). When asked to declare a major, with hardly a blink of the eye, I wrote: Civil Engineering.
After only one year in engineering, however, it was clear that the engineering curriculum, in those pre-Sputnik days, was not very exciting. In due course, I changed my major to mathematics with minors in physics, statistics and psychology. Most importantly, I married Muriel Farrell, a student in applied art.
As I progressed through the curriculum at ISU I was strongly attracted to pure mathematics, more so the further I went. I left ISU with BS and MS degrees in mathematics. Professor B. Vinograd guided my Master’s thesis, “Second Order Linear Representations of Continuous Groups,” and tried to persuade me to apply to the graduate program in Mathematics at the University of Wisconsin to study topological algebra under Professor W. F. Eberlein.
We were in a theater, whose name I do not now recollect, in downtown New York, on Broadway, engrossed in Lee J. Cobb’s superb performance in “Death of a Salesman.” I was accompanied by two members of the Technical Staff of Bell Labs. After a recruiting visit to the ISU campus, Bell Labs invited me to visit New York. They said I could work either there or at Sandia in New Mexico, and they would support me in further graduate work. The offer was very tempting but Muriel and I finally decided to go on to the University of Wisconsin where I would continue my study of pure mathematics.
I thoroughly enjoyed my courses at the University of Wisconsin, Madison (UWM): logic with Kleene, point set topology with Bing, topological algebra with Eberlein and Fullerton, measure and integration with Young, group theory with Bruck, algebra with MacDuffee, complex analysis and partial differential equations with Langer.
That enjoyment was soon to be attenuated by very practical matters: The arrival of our son Farrell (1950) and of a daughter Darcy (1953) and the expiration of my GI Bill benefits. At various times throughout our residence in Madison, I held part-time jobs: research assistant, teaching assistant, correspondence teacher, draftsman, and, for two years, a full night shift for the Gisholt machine tool company (horizontal boring mill), never all at once, but several at a time frequently. Muriel says it seemed like more than several. Fortunately, she was able to impose strict frugality measures on herself and the family, measures she had learned from her mother during the depression of 1929-1941. It was only through her deft management that we survived and I was able to continue my work at the University.
Finally, I finished all requirements for the PhD degree except the dissertation. I knew that I would have to have some quality time, possibly as much as a year, to focus on research. Muriel’s parents had helped us to buy a house but I still needed to provide income in such a way that would leave me time for research.
Professor Preston C. Hammer was a member of the faculty of the Math Department who taught, primarily, numerical analysis and ran the Statistical Laboratory for the scientific community. He had been recently hired from the scientific staff at Los Alamos as part of an effort to give the Math Department more of an “applied” look, or so it appeared to us pure math students. He was a colorful figure and the only faculty member who would occasionally join the graduate students in their coffee room. I knew that Professor Hammer hired assistants to work in the Stat Lab, and I was so desperate to solve the problem of having quality time for research that I proposed to him jokingly that, for the sake of the advancement of mathematics, he should give me a sinecure from the Stat Lab and I would work on my dissertation full time. To my vast surprise he accepted my proposal! The following week he bestowed upon me the title of Assistant Project Supervisor and a desk in the corner of the Lab. Without the slightest portent of impending disaster, I eagerly went to work on my research.
What Professor Hammer hadn’t told me was that, by the end of the summer, everyone who worked in the Lab, the Project Supervisor and all the student assistants, for one reason or another, would depart the Lab. That left only Professor Hammer and me, and Professor Hammer only made policy; he didn’t work on projects.
I resisted as long as I could the clamor for service made by disappointed clients and would-be clients of the Lab. Finally, I surrendered to the facts that Professor Hammer was in no hurry to hire new people and that my sinecure had evaporated. I set aside my research, collected all the manuals for the machines available in the Lab and started to teach myself how to run them: the key punch, the sorter, the collator, the IBM 602 punch card computer (wire panel programmable). We also had a very strange lash-up of a computer system consisting of an IBM 604 punch card computer, an accounting machine (about the size of a grand piano) for reading programs in on punched cards and printing output, and three “B” boxes (metal cubes about 3 x 3 x 3 feet on wheels) each containing only 8 ten digit words of mechanical memory (counting wheels). This served for all our more sophisticated floating point computations. Professor Hammer promoted me to Project Supervisor and we started to hire and train new student assistants.
In spite of my years of exclusive devotion to pure math, I began to appreciate the variety of work that came through the Lab, not only from all branches of science and engineering but also from the social sciences, agriculture, medicine and law. I was becoming interested in some concepts new to me: operations research, mathematical modeling and simulation. In a sense, I had come full circle from engineering to pure math and back to applied math and engineering.
It was three o’ clock in the morning and I was bent over our floating point computer immersed in the patterns of the numbers emerging from the printer. They were part of a study that we were doing for the Baker Manufacturing Company on the design of hydrofoil boats. Their design problem had been reduced to the solution of a set of simultaneous linear equations with complex coefficients some of which were design parameters that could be varied to find the best design. On another occasion we had a project with Oscar Meyer & Co., concerning the statistical design and analysis of surveys. Thus, did Professor Hammer introduce me to the role of academic consultants in industry.
We were all excited when we got word that IBM had accepted our proposal to be among the first Universities to install IBM’s 650: a stored program computer with 2000, 10-digit words of magnetic storage on a rotating drum; such computer power! or so we thought then. I began to develop and teach courses in programming, numerical analysis and statistical analysis through the Math Department but primarily for Lab clientele. We changed our name from Stat Lab to Numerical Analysis Laboratory.
It was a hot spring day in June, Professor Eberlein and I were standing in line perspiring in our academic garb, waiting for our names to be called. In spite of everything, including a waning interest in pure math, I had managed to submit a dissertation acceptable to the Math Department entitled, “On Weak Compactness in Functional Analysis.” Functional analysis then meant, roughly, the study of an abstract space by means of the functions defined over the space. Functional analysis would come to have a vastly different meaning for me than the one intended in my dissertation: functional analysis is the name of an important methodology for systems engineering and design of complex systems.
After earning the PhD degree and acquiring some relatively extensive experience in digital computers, Muriel and I were pleased to find that my market value had gone up considerably. It was time to leave the University. The result of an extensive search for the right job was a family move to Arlington Heights, Illinois, where it was a short commute to the Research Laboratories of the Pure Oil Company at Crystal Lake. I was given the title of Mathematical and Computer Consultant. The Labs were set in a beautiful campus, the professional personnel were eager to learn what I had to teach and to include me in many interesting projects where my knowledge and skills could be put to good use. I was encouraged to initiate my own program of research. I went to work with enthusiasm.
The corporate headquarters of Pure Oil were located in down town Chicago. Pure Oil had been trying to install an IBM 705 computer system for all their accounting needs including calculation of all data necessary for the management of exploration, drilling, refining and distribution of oil products and even royalties to shareholders in oil wells. Typical for those early days, the programming team was in deep difficulties and needed help; they lacked adequate resources and suitable training. The Executive Vice President of Pure Oil, when he heard that there was a “computer expert” already on the payroll at the Crystal Lake lab, ended our family’s blissful dream and I was reassigned to the down town office.
During this period I was able to carry out only one project of real interest to me. Pure Oil was a fully integrated oil company in the sense that they engaged in exploration for oil, construction of oil wells, production of crude oil, transportation to refineries, distribution of refinery products to company owned storage facilities and to gas stations. We developed a linear programming model of the whole network hoping to discover the optimum allocation to and from connected nodes in order to meet required deliveries at minimum cost. Then we collected all the data needed by our model and ran the model. The computations took several days and the results were disappointing: The optimum allocations were not significantly different from their current practices. Is it possible that we had discovered a system of human beings in which everyone knew the payoff functions and constraints, and, over time, had evolved behavior patterns that enabled them to achieve near optimum performance? Or was it possible that our model was not detailed enough as it was based so closely on current practice that no new behavior could emerge? Or was our data incorrect? This was disappointing but great experience.
The commute from our house was over an hour each way by car and by train. Living in Ames, Iowa, and Madison, Wisconsin, had not prepared us for life as a suburban family commuting to Chicago, even though Muriel had been raised in that same suburban region. It didn’t help much that I was designated to be on “The Executive Fast Track” and, for diversion, was teaching an evening course in numerical analysis for the Illinois Institute of Technology.
We decided to leave Chicago and, in order not to end in the same situation again, we were determined that I seek a position in a university that might be trying to establish a Lab similar to the one at Wisconsin; we hoped there might be quite a few such universities. We set up requirements – academic (had to offer PhD degrees in engineering and math), the size of the city (no more than 100,000 population), size of the university and a warmer climate, for examples - and, from a directory of American Colleges and Universities, winnowed our choices to twenty. We wrote to every one; we received a positive response from every one.
Among the first and most enthusiastic responses to our enquiries was the University of Arizona, from the office of the Dean of Engineering. They had just installed an IBM 650 and were looking for a person to direct the operation of the computer center. The salary was competitive, all our other requirements were met. I knew that I would appreciate living in the desert having spent a tour of Army duty in Talara, Peru, located in the desert of northern Peru. I was sure that the rest of the family would acclimatize without difficulty, particularly since Mexico was not far away with its interesting culture and beautiful beaches; Muriel loved to travel and all of us enjoyed the water. Besides, there was folk wisdom on the campus of the University of Arizona that said, “You may not like the climate of Tucson but after you have been here two years, you wont be comfortable anywhere else in the world,” and, more specifically, “After two years, new faculty will have lost their professional mobility because they wont be able to move their families away from Tucson.”
I accepted the position of Director of the Numerical Analysis Laboratory and Professor of Electrical Engineering (!) at the University of Arizona. The Numerical Analysis Laboratory was under the Dean of Engineering (since he put up most of the initial money and all the facilities) but served the entire University; it evolved into the University of Arizona Center for Computing & Information Technology.
I was alone in my office completely absorbed in what, I don’t now recollect. I was busy all the time: I gave lectures to individuals and groups on how the computer could be used by research faculty in diverse fields; I wrote computer programs; I developed and taught courses in programming, numerical analysis, statistics and operations research; I wrote proposals to upgrade the computer equipment. I must have been engaged in one of these activities when Dr. Thomas L. Martin, then Dean of Engineering, came into my office, sat down and immediately began talking:
“I have just returned from an exciting meeting of the American Society for Engineering Education where I heard a paper on the new discipline of systems engineering. It is no longer sufficient for engineers merely to design boxes such as computers with the expectation that they would become components of larger, more complex systems. That is wasteful because frequently the box component is a bad fit in the system and has to be redesigned or worse, can lead to system failure. We must learn how to design large-scale, complex systems from the top down so that the specification for each component is derivable from the requirements for the overall system. We must also take a much larger view of systems. We must design the man-machine interfaces and even the system-society interfaces. Systems engineers must be trained for the design of large-scale, complex, man-machine-social systems.”
This quotation is vastly abridged, I am sure, but it communicates the tone and some of the principal points as I recollect them. I was not paying too much attention, still absorbed in what I had been doing, and besides, when I heard the words “American Society for Engineering Education,” I am sure that my eyes began to glaze over. Then the Dean, undeterred by my lack of attention or perhaps so absorbed in his monologue that he didn’t notice, continued:
“The next big development in engineering education will be the establishment of systems engineering as an engineering discipline. The University of Arizona is going to have a Department of Systems Engineering and I want you to develop and head up the Department.”
Upon hearing that last sentence, I came fully to attention wishing I had listened more closely to his previous words. I sometimes characterize my intellectual life from that day to the present as trying to recall and to make sense of what the Dean had been trying to tell me that day in 1958.
I was captivated by the grandeur of the vision invoked. I had just begun to appreciate the possibilities for more complex systems because computers were certain to become available with much faster performance, more memory and cheaper cost. I had glimpsed some of the interesting, even mathematical problems in the structure of computer programs but had yet to explore the possibilities for research in what was to become computer science. I had already come to realize it wasn’t the computer or the programs or the user, it was the system.
Before I could dwell on these interesting intellectual possibilities, there were myriad administrative tasks to be accomplished having to do with financing and budgets for the new department, office and laboratory space, faculty recruitment, course and curricula development and pitched political battles to win the acceptance of the new department by the Faculty of the other departments of the College of Engineering.
I had also to assess the literature in systems engineering. There wasn’t much at that time (circa 1958) that satisfied both my mathematical standards and my hopes for what might be accomplished in systems engineering. The literature on control systems was already quite large and I found these sources interesting but inadequate as tools for systems engineering. There was, on the other hand, some hope for rigorous mathematical treatment of theories of systems in the developing theories of automata, sequential machines, etc., going all the way back to [Turing, 1936]. Automata Studies, edited by C. E. Shannon and J. McCarthy, containing papers by Ashby, Davis, Kleene, Moore and Von Neumann, among others, was published in 1956. When I discovered this work I was very excited because I knew that modeling and simulation would be very important to systems engineering.
I found no other academic departments of systems engineering offering degrees. As far as I have been able to discover, the Systems Engineering Department at the University of Arizona is the world’s first academic department of systems engineering to offer degrees in systems engineering.
Where, in academia, I did find interest in the concept of systems engineering, I also heard, “Well, but we already teach that in control engineering,” or “...in industrial engineering.” They did not - to my satisfaction. In fact, over the subsequent years, every time we would submit our undergraduate program for accreditation, we were asked if we wanted an inspector from control engineering or from industrial engineering. The International Council on Systems Engineering (INCOSE) is still trying (2004) to persuade ABET, the engineering accrediting organization, to allow INCOSE to assign inspectors for accreditation of eligible systems engineering programs.
There was, however, interest in systems engineering outside academia. Some governmental and industrial organizations already claimed to be doing systems engineering. In order to educate myself in systems engineering, I hit upon the strategy of seeking consulting opportunities in these organizations. They accepted that my only credentials in the field were that I was Head of a nascent Systems Engineering Department at the University of Arizona, I had computer experience, and I was eager to learn what they were doing in systems engineering. I spent most University holidays, throughout my academic career at Arizona, consulting in governmental, non-governmental and industrial organizations whereby I was able to involve myself in virtually every aspect of systems engineering. I did not encourage repeat engagements when I felt there was little more to learn from an organization; I wanted to experience systems engineering in diverse fields of application involving as broad a spectrum of stakeholders, functions and technologies as possible.
During the academic year, my research consisted in developing methodology and mathematical theory useful to solve the problems and dispel the confusion I found in my consulting work. The developing theory was mathematically rigorous yet addressed directly to the practical problems of systems engineering.
My students and I applied the developing theory and methodology, pro bono, to system design problems involving stakeholders and functional and technological contexts available to us in the Tucson community.
The Department of Systems Engineering eventually offered Bachelor of Science, Master of Science and Doctor of Philosophy degrees in Systems Engineering. The undergraduate program was fully accredited. Curricula and research in the Department of Systems Engineering were based in seven areas: probability and statistics, operations research and optimization techniques, computer science and numerical analysis, mathematical system theory, human factors, engineering mathematics, and engineering economics.
See [Wymore, 1969a], for the historical basis for curriculum design, [Bahill, 1992], and [Unwin, 1993], for history of the Department of Systems Engineering at the University of Arizona.
“What is a system?
“Is a rock a system?”
“No, a rock just sits there; it is not a system.”
“Yes, a rock has inputs causing the rock to weather and erode and pressure from surrounding rocks may cause the rock to evolve into a diamond!”
“Is the University’s registration process a system?”
“No, it is too irrational and chaotic.”
“Yes, it is a system because it has inputs and responds to those inputs to produce outputs, however inefficient and irrational it seems.”
These are archetypal ripostes offered of a Friday evening at the Wymore’s where all the graduate students gathered to discuss, informally, systems and systems engineering.
From such discussions we concluded that each person has an internalized notion of what constitutes a system. In order to be able to communicate precisely about systems we needed to have a formalized definition of the system concept. “System” would not be an undefined term in the theory of systems engineering that we were developing.
To formalize, mathematically, the concept of “system” was the objective of my first book, A Mathematical Theory of Systems Engineering, The elements. I tacked The elements on the title because I realized there was much more to systems engineering than I was able to include in the book but that the material in the book must be fundamental to the theory and practice of systems engineering.
Here are a few of the highlights of A Mathematical Theory of Systems Engineering, the Elements [Wymore, 1967]: I proposed a definition of a set, call it SYSTEMS, of system models that included models having a broad class of time scales including the nonnegative integers and the nonnegative real numbers. The definition is mathematically rigorous based on set theoretic concepts. I showed that Turing machines, sequential machines and systems based on differential equations could all be represented by models in the set SYSTEMS. I developed a theory of the relationships of homomorphisms, isomorphisms and equivalences among members of SYSTEMS. I developed a theory about how input/output relations could be used to specify coupling of system models, including feedback loops, and conditions under which the resultant of such a coupling belongs to SYSTEMS. I did not want the developing theory of systems engineering to be restricted to the “loop-free” case.
The day began unusually dark and blustery on the island of
Oahu in the Hawaiian Islands on the Winter Solstice, December 21 of 1967. Our
family, by this time expanded to include two more daughters, Melanie (1962) and
Leslie (1964), had relocated to Honolulu where I was going to spend my first
sabbatical leave to write another book, Systems Engineering Methodology for Interdisciplinary Teams. The
inclement weather appeared to be improving and everyone, including Muriel’s
mother and a friend of Darcy who was visiting us, wanted to go to the beach for
a swim and lunch. We went to Makapuu beach, a favorite of body surfers, where I
hoped to give the children a lesson in body surfing.
I had already caught a couple of
waves successfully, which means that the surfer times his swimming with the
wave so as to slide down the front of the wave just as one would do on a surf
board, and rides the dying wave to the beach.
This time, there was some unexpected turbulence or my timing was off,
but whatever it was, instead of sliding smoothly down the front of the wave, I
found myself on the crest of the wave just as it began to break and “went over
the falls” as they say in surfer jargon. The waves were 8-10 feet high and the
beach had a considerable slope of very hard sand and I hit the sand on the top
of my head. I literally heard the internal flash of lightning down my spine,
saw the oncoming darkness and I knew that if I lost consciousness I would
drown. My life did not flash before my
eyes but I was filled with an overwhelming sense of regret that I would not see
my family grow up nor finish my scientific work. The darkness descended. Then I
woke and opened my eyes; I was underwater and I could see but could not feel my
arms; absurdly, I thought I had broken my arms - the darkness descended again.
The next thing I knew I was sitting on the sand facing away from the beach with
legs spread and torso supported by my arms and hands behind me. The surf was breaking over my head and I was
not breathing. I took a deep breath and started shouting, “Help.” My daughter Darcy had been looking for me as
I tumbled around in the surf and she with the help of several strangers dragged
me out of the water. Fortunately, among the rescuers was a nurse who knew
immediately what had happened and took charge so as to prevent any further
damage to my broken neck while the ambulance was on its way.
Muriel, consulting with Dr. Jacobson, a neurosurgeon at Queen’s Hospital, insisted that he give her an honest prognosis of my condition because we were visiting the islands virtually alone with four children and she needed to know what she was facing. He said, “If he does not die of pneumonia tonight he will spend the rest of his life in a wheel chair and someone will have to feed him because he is quadriplegic.” Muriel spent the night by my bed making sure that I continued to breathe; even my autonomic nervous system seemed to have been severely damaged.
The next day they shaved my head, drilled two holes, one on ether side of my skull, inserted the ends of a pair of tongs in the holes and attached the tongs to a weight that was suspended above my head over the edge of the gurney on which I was lying. They were trying to straighten my spine prior to surgery. The surgery consisted primarily of cleaning up the mess of two smashed cervical vertebrae, realigning my spine and inserting bone grafts to stabilize my neck. After two weeks I was transferred from Queen’s hospital to the Kapiolani Children’s Hospital and Rehabilitation Center once reserved for the wounded of the Korean war. It was Friday and the next day was New Year’s Eve. The hospital was on minimal staff for a four day weekend and I felt abandoned and totally despondent, even suicidal. The support of my wife, Muriel, son, Farrell (a teenager in a rock and roll band), and daughters, Darcy (in junior high school), Melanie and Leslie (both in preschool), was critical. Muriel’s mother’s help was essential; she looked after the children and the household so that Muriel could spend time with me at the rehab center.
The following week, Dr. Shepard, Director of the Rehabilitation Center conducted an evaluation of my condition which seemed to me to consist mainly of poking my feet with a needle to elicit any reaction at all. I neither saw nor felt anything but Dr. Shepard and my wife both claimed that they saw my big toe twitch a little. Dr. Shepard promised virtually complete recovery. So I became a full time athlete for a year or so: I participated in occupational therapy in the morning to regain functions of my fingers and hands with Mrs. Chi and physical therapy in the afternoons to learn to crawl and then to walk with Mrs. Leslie. I sometimes thought of these women as sadistic torturers, but it is to them that I owe the realization of Dr. Shepard’s promise.
Six months after the accident I was not completely functional but at least independent and we returned to Tucson. It took another year of self imposed therapy before I attained almost complete normalcy. I had resigned my position as Director of the Numerical Analysis Lab before we went to Hawaii, but I resumed the Chairmanship of the Department of Systems Engineering and continued my research and teaching with renewed vigor and enthusiasm, in wonder at being alive and fit.
George Viehmeyer was Manager of the Military Systems Requirements Division of the Lockheed-Georgia Company and lead systems engineer on the design of the C5A (a huge military cargo airplane). George attended a lecture that I gave at Georgia Tech in the Spring of 1969. Afterward, he asked if I might be interested in spending the summer at Lockheed-Georgia to study and evaluate the systems engineering process employed in the C5A program. It was clear that there were serious problems: three prototype C5As were already parked on the apron while George's people were still filling out systems engineering forms required by USAFSC 375-5 and Mil Std 499, as I recall. People were specifying system functions like, "Provide power supply." "Whose function is that?" George asks, and, "What is system functional analysis anyway?" Engineers outside the systems engineering group said things like, “I don’t know what those guys in systems engineering are doing, but we’re designing an airplane.” George appointed a system functional analysis study group to work with me.
A Mathematical theory of Systems Engineering, the Elements [Wymore, 1967a] discussed modeling of systems but very little about requirements, what they are and how they are developed. I had introduced, rather clumsily, what I called a technical system specification; this notion eventually evolved into the input/output requirement. Even so, in 1969, I was still very much in a learning mode as far as a mathematical theory of systems engineering was concerned.
It was there we discovered (for ourselves, at least) that, in all cases except the very simplest, there are more ways than one to accomplish system functional analysis. We had decided that system functional analysis is the specification of a set of subsystems and the interfaces among them which will accomplish the top level function. System functional analysis also includes the specification of the requirements for the design of each subsystem consistent with the requirements at the top level in the following sense: if the requirements for every subsystem are satisfied by the subsystem, then the top level requirements will be satisfied by the system resultant from suitably interconnecting the subsystems.
I had gotten up very early in order to get in some jogging before going to work at Lockheed. I was jogging through our apartment complex, when it occurred to me in midstride that we could define an input/output requirement consisting of:
a timescale, defining the operational life of the system,
a set of inputs,
a set of input trajectories,
a set of outputs,
a set of output trajectories and
an “eligibility” function, that, for each input trajectory, specified a subset of output trajectories that were desirable or not impossible (with respect to conservation of mass and energy, for examples) for a system to produce, given the input trajectory.
I realized it was important to deal with trajectories rather than with individual inputs and outputs because the behavior of most systems of interest depends on the past history of inputs, not just the last input. I thought of an information retrieval system, with two kinds of input: information and queries for information. The same query submitted at different times will elicit different responses depending on the input of information during the interim between the queries.
Then it came to me so hard that I had to stop running to concentrate on the action in my head: “The I/O requirement generates the space of functional system designs and, dually, there must be a space of buildable system designs generated by a technology requirement consisting of the set of components eligible to be used to build systems through system coupling recipes to implement the functional system designs.”
That is the way it came to me: all in a rush. I started running again, frantic to get back to the apartment where I could write it all down. Here was the beginning, for me, of a mathematically rigorous structure for system design requirements, recognition that there need be only 6 mathematical objects (some very complex to be sure) with which to state system design requirements: I/O, technology, performance, cost, tradeoff and system test. The first publication of the theory came in 1976 with the appearance of the book, Systems Engineering Methodology for Interdisciplinary Teams [Wymore, 1976a]. The style of that book was not completely rigorous intended as it was for an “interdisciplinary” audience. The rigorous mathematical development of the theory did not appear until 1993 with the publication of Model-based Systems Engineering [Wymore, 1993a].
Quetzals are large birds with particularly gaudy and plentiful plumage; they are beautiful, well worth seeing in the wild. Muriel and I were sitting under a very large tree in Monte Verde, a Costa Rican national park. The manager of the posada where we were staying told us that if we would wait beneath this particular tree, the quetzals would surely come.
Two years earlier, David Franklin, a former student, told me that USAID was sponsoring a “systems” study of the production of food in Central America: as I recall, at that time, something like 80% of the food consumed in Central America was produced on farms of one hectare (about 2.5 acres) or less; the population of Central America was growing, the food production of these small farmers was decreasing.
My curiosity was aroused and I was eligible for a sabbatical. David arranged for me to visit the Centro Agriculo Tropico de Investigacion y Enseñanza (CATIE, Center for Research and Teaching in Tropical Agriculture), near Turrialba, Cost Rica, about 30 miles from San Jose, the capital of Costa Rica. CATIE was to be the headquarters for the study. A deal was made and all we had to do was to obtain the approval of USAID headquarters in Guatemala City.
Time passed and the necessary approval did not arrive. We held a family counsel and decided that, even if we hadn’t heard from USAID, by the 15th of January, we would leave Tucson by car, Muriel, three daughters and I, and drive to Guatemala City. If USAID didn’t support our participation with the project in CATIE, then we would return to Tucson, having enjoyed a vacation trip through Mexico and Guatemala. If we got the support of USAID, we would continue to drive on to Costa Rica. USAID gave us the support we needed.
In the folklore of systems engineering, there are sayings, “If it isn’t testable, it isn’t a requirement,” and, “If it is not quantifiable, it is not testable.” I had always tended to subscribe to the particle of wisdom in these sayings. One of the many lessons that I learned from the CATIE experience, however, was that systems engineering had to be able to deal directly and purposively with what are usually considered to be strictly qualitative (unquantifiable) aspect of systems, such as quality of life, for example. The agricultural practices of these small farmers in Central America is such a large part of their lives that to change any part of their agricultural practices might be seen as diminishing their quality of life - even with respect to the color of the beans that the new practices might require. But even if we cannot deal directly with quality of life or user friendliness or enmity/sympathy, we can identify quantifiable figures of merit relating to these qualitative aspects and if we find enough figures of merit and combine them suitably, we might eventually obtain agreement that we have captured the essence of the qualitative aspect, at least as far as this particular set of stakeholders is concerned.
“Combining them suitably” would necessarily involve parameters, the values of which could be assigned by individual stakeholders to reflect personal priorities. But the assignment of priorities can only be meaningful if the number of figures of merit to be prioritized is in the range defined by the magical human factors numbers 7 ± 2 [Miller, 1956]. If one prioritizes and combines one group of 6 figures of merit and another group of 7 figures of merit, then one has created two new figures of merit which have to be prioritized and “suitably combined” to produce one figure of merit related to the desired qualitative aspect. There may be required hundreds, perhaps thousands of such quantifiable figures of merit to define one qualitative aspect in a very complex system.
Each figure of merit is a function defined over a set of system models (representing designs) with values in the real numbers. Two such figures of merit may represent incomparable apples and oranges. So systems engineering and the stakeholder can assign to each figure of merit a scoring function with values in the interval of real numbers between 0 and 1 such that the greater the score implies the more desirable value for the underlying figure of merit.[1]
These questions about qualitative aspects of complex systems were only a subset of the myriad questions that I took back to Tucson with me representing a great deal of research to be done. My mind kept chewing, however, on the idea of scoring functions. I wanted each scoring function to involve parameters: maximum (above which the value of the scoring function is 1), minimum (below which the value of the scoring function is 0), baseline (the value of the figure of merit for the legacy system, or goal for the figure of merit, for which the score is 0.5) and the slope of the scoring function at the baseline value (which represents the stakeholder’s feelings about the baseline value (small slope if the stakeholder is indifferent, large slope if the stakeholder wants to motivate movement away from the baseline value).
I decided that I wanted first a continuous function f, defined over the real numbers with values in the real numbers between 0 and 1 which was strictly increasing, that takes on the value 0 at the minimum where it is also tangent to the x-axis, takes on the value 0.5 at the baseline with a specified slope at the baseline value, and approaches 1 as x goes to infinity. In this case the maximum is infinity, the shape of an elongated S. I found that with one such standard scoring function I could create many shapes representing stakeholder preferences simply by elementary transforms, cutting and pasting, concatenation. Furthermore, I wanted this standard scoring function number 1 to be an algebraic function not a transcendental function whose value could only be approximated.
Two years after our residence in CATIE, I was invited for another visit to CATIE to serve on a panel to appraise progress in the study. After that exercise was complete Muriel and I decided to rent a car to see some of Costa Rica that we did not see on our first visit. One of those places was Monte Verde National Park.
We sat a long time under that huge tree waiting for the quetzals to arrive. Suddenly, we heard a rustling of leaves and the sound of fruit, stones and other droppings hitting the ground around us. At that exact same moment, my subconscious presented me with the formula for standard scoring function number 1 perfect in every detail.[2] I searched frantically for pen and paper. Muriel had a book of matches and a pencil in her purse. Fortunately, I got the formula down correctly and verified all the properties after returning to the posada. I have never since been without pen and paper very close to hand. I never saw the quetzals.
I woke with a start one morning in January, 1987, with the realization that soon I would be 60 years old and that in July I would have served on the Faculty of the University of Arizona for 30 years; furthermore, and more importantly, 60+30=90. According to the rules of the State of Arizona, I could retire with full benefits. On the other hand, I could remain on the faculty until I was 75 or so.
Muriel and I discussed the matter and decided that I should take retirement. I could still teach in the Department and/or continue my consulting activities, if necessary. Otherwise, I would have complete charge of my work schedule and calendar with no tiresome meetings to attend or reports and proposals to write. We would be able to travel together and to spend more time with our children and grandchildren.
Now (1987) I had a chance to finish the book on which I had been working for 11 years, since the publication of Systems Engineering Methodology for Interdisciplinary Teams in 1976. This was to be the book that I write for myself, for pleasure, with little regard for the existence of a market. It would be mathematically as rigorous as I was able to make it and it was intended to include every aspect of system science that would be necessary for successful systems engineering. The rigor doubtless would be tedious for the present day systems engineer. It might take a generation or two, perhaps more, before the profession would see fit to train systems engineers at a sufficiently high level of mathematical sophistication to qualify themselves to take on the design of a really vast and complex system such as the national health care system.
I decided early on that I would restrict all of MBSE to discrete time and that the basic set of system models would be the set of sequential machines with Moore readout functions. (The output of a system model is a function only of the state of the system and is independent of the instantaneous input.) These decisions freed me from topological considerations occasioned by aspects of continuous time and allowed me to concentrate on the mathematical structures of the objects of interest to systems engineers.
The book begins with a discussion of the definition of systems engineering, a nonmathematical description of a systems engineering process and of the theory which is to be the subject of the rest of the book.
After this introductory chapter, the book turned out to be composed of three distinct parts [Klir, 1996] of about equal size:
an extensive appendix that lists all the notation used in the book, presents a detailed exposition of the set theory on which the system science is based and examples of every mathematical object discussed in the text;
an extensive development of the mathematical system theory on which the systems engineering methodology is based;
the systems engineering methodology itself.
I have always preferred to publish in book form rather than to submit papers to journals. I know that papers in journals carry more academic weight than books, but I feel stifled by the length restrictions and other arbitrary specifications such as format, etc., required by journals. My negative attitude toward journal publication stems partly from my days in the Numerical Analysis Lab at the University of Wisconsin. Professor Hammer was a free thinker and he was always trying to get his ideas published in peer-reviewed journals. He would spend months in painful argument by mail with reviewers of his papers. Typically, he clearly spent more time and more emotional energy in the review process than he did writing the paper. For me, it is the research and writing that I enjoy, not necessarily the publication itself. With the internet, I can publish whatever and whenever I wish with relatively little pain.
What follows is a brief discussion of the areas of research that I intend to pursue. Research in a given area may generate one or several books or papers or internet postings.
MBSE established a mathematical framework for the statement of the problem of the design of a system; it did not provide a mathematical structure which would lead to the actual design of the system. That is the basic theme of MBSE2.
I presented a paper with this title at the International Symposium of the International Council on Systems Engineering in Brighton, England, 1999. The theme is to speculate how misunderstandings, errors or omissions in the system design process as described in MBSE and MBSE2 might lead to ultimate failure of the deployed system.
I have posted a paper on my website with this title. That paper, I have subsequently found, is only the beginning of possibilities for allocating top level requirements to subsystems (or the derivation of subsystem requirements from top level requirements) in such a way that optimum designs of the subsystems would ensure optimum design of the resultant system with respect to the top level requirements.
Classical theory, see [Gill, 1962, Theorem 3.6, page 76] for example, proves that for every system model Z there is a system model Zmin which has the same input set and output set as Z, is a homomorphic image of Z and has a minimal number of states to achieve the same input and output behavior as Z. Any other system that satisfies these relations is isomorphic to Zmin. I have developed, and subsequently applied, a dual theory concerning the existence and properties of a maximal system model Zmax for every system model Z.
The project here is, essentially, to rewrite MBSE and MBSE2 in which the system models are defined for continuous time.
There are systems that have some subsystems that are best modeled as discrete time systems and other subsystems that are best modeled as continuous time systems. How are such systems best modeled for simulation purposes? One approach to this problem is through the use of maximal system models.
I am certain that new and wonderful vistas of systems science and engineering will appear as I explore the landscape in my present purview.
Gill, A., Introduction
to the Theory of Finite State Machines, McGraw-Hill, New York, 1962.
Keeney, R. L. and H. Raiffa, Decisions with Multiple Objectives:
Preferences and Value Tradeoffs, John Wiley, New York, 1976.
Klir, G., Review of Model-Based Systems Engineering, in the International Journal of General Systems, George Klir, Editor,
Volume 25, Number 2, pages 179-180, 1996, Gordon and Breach, Amsterdam, 1996.
Miller, G. A., “The magical number seven plus
or minus two: Some limits on our capacity for processing information,” in Psychological Review, 63, pages 81-97,
1956.
Moore, E. F., “Gedanken-experiments on
Sequential Machines,” in Automata Studies,
edited by C. E. Shannon and J. McCarthy, Princeton University Press, Princeton,
NJ, 1956.
Turing, A. M., “On Computable Numbers with an
Application to the Entscheidungs Problem,” in Proceedings of the London Mathematical Society, Series 2, volume
42, pages 230-265, 1936.
Zadeh, L. A., “Fuzzy Sets,” in Information and Control, Vol. 8, No. 3,
pp. 338-353, June, 1965.
System
Functional Analysis and System Design, Phase 2 of Model-Based Systems
Engineering, to appear.
Model-Based
Systems Engineering, CRC Press, Inc. 2000 Corporate Blvd., N.
W., Boca Raton, FL 33431, 1993a.
Engineering
Modeling and Design, CRC Press, Inc. 2000 Corporate Blvd.,
N. W., Boca Raton, FL 33431, 1992 (third author with W. L. Chapman (first author)
and A. T. Bahill).
Systems
Engineering Methodology for Interdisciplinary Teams,
John Wiley & Sons, New York, 1976a.
A Mathematical
Theory of Systems Engineering: The
Elements, John Wiley & Sons, New York, 1967a.
"Theory of Systems," in Handbook on Software Engineering, edited
by C. R. Vick and C. V.
Ramamoorthy, Van Nostrand Reinhold Company, New York, 1984, pages 119 -
133.
"The Tricotyledon Theory of System
Design," in Simulation and
Model-Based Methodologies: An Integrative
View, edited by T. I. Oren, B. P. Zeigler and M. S. Elzas, Springer-Verlag,
New York, 1984, pages 119 - 132.
"The Tricotyledon Theory of System Design
as a Modelling Methodology," in Adequate
Modeling of Systems, edited by Horst Wedde, Springer-Verlag, Berlin, 1983,
pages 185 - 203.
"On the Introduction of Modern
Agricultural Technology in a Developing Country," in The Application of Technology in Developing Countries, edited by R.
L. Bulfin, Jr. and J. R. Greenwell, Office of Interdisciplinary Programs,
Office of Arid Lands Studies, The University of Arizona, Tucson, Arizona,
1976b, pages 117 - 153.
"The Tricotyledon Theory of System
Design," in Category Theory Applied
to Computation and Control, edited by E. G. Manes, Lecture Notes in
Computer Science, Springer-Verlag, New York, 1975, pages 224 - 230.
"A Wattled Theory of Systems," in Trends in Mathematical System Theory,
edited by G. J. Klir, John Wiley & Sons, New York, in 1972, pages 270 -
300.
"Discrete Systems and Continuous
Systems," in Advances in
Mathematical System Theory, edited by P. C. Hammer, The Pennsylvania State
University Press, University park, Pennsylvania, 1969c, pages 9 - 45.
Concept of
Operations (CONOPS) of a Systems Engineering Education Community (SEEC),
dated 3/15/2004; published by INCOSE: Seattle WA; copies and reprints available
from the INCOSE Central Office, 2150 N. 107th St., Suite 205, Seattle, WA
98133-9009, 2nd author with J. Ring.
Un Bosquejo de
los Conceptos Basicos de la Ingenieria de Sistemas,
Publicacion No. 51, Universidad Nacional Agraria, "La Molina,"
Departamento de Recursos de Agua y Tierra, Lima, Peru, 1977.
Administration
of Programming Effort, Computer Laboratory, Department of
Electricity, United States Military Academy, West Point, New York, 1962.
“The Nature of Research in Systems Engineering,
Paper Session 2.1.1,” 211-Paper 119 in Proceedings
of the Conference on Systems Engineering Research, University of Southern
California, Los Angeles, California, April 15-16, 2004, CD ROM published by
Honourcode, Inc., http://www.hcode.com
, and duplicated by the USC Center for Software Engineering.
“A System Theoretic Framework for V&V,
Paper Number 2.2.2,” in 12th Annual Symposium of the International
Council on Systems Engineering (INCOSE), July 28 – 1 August 2002, Las Vegas,
Nevada, CD produced by Electronic Imaging services, 1570 Oak Avenue, Suite 100,
Evanston, IL, 60201, www.eiservices.com.
“Fomenting the
Systems Engineering Revolution, a working paper for the Panel, ‘Is SE Evolving
Fast enough?’” presented to the Academic Forum and in Session 5.2 in 12th
Annual Symposium of the International Council on Systems Engineering (INCOSE),
July 28 – 1 August 2002, Las Vegas, Nevada, CD produced by Electronic Imaging
services, 1570 Oak Avenue, Suite 100, Evanston, IL, 60201, www.eiservices.com.
“When Can We Safely
Reuse Systems, Upgrade Systems, or Use COTS Components?” in Systems
Engineering, The Journal of the International Council on Systems Engineering,
Volume 3, Number 2, 22 May 2000, pages 82 - 95 (first author with Terry
Bahill).
“System Theoretic
Portents of Predisposition to System Failure,” in Systems Engineering: Sharing the
Future, Paper 2, Session 2.4 of the (CD)Proceedings of the Ninth Annual
International Symposium of the International Council on Systems Engineering
(INCOSE), Brighton, England, 6-11 June 1999, Allen Fairbairn, Ed., awarded Best
Paper in Research and Education.
“A
SystemTheoretic Fable in which Serious Misunderstandings Occur among Systems
Engineers” at
http://www.sie.arizona.edu/faculty/wymore.html, 1998
“The Design-Methods Comparison Project,” in IEEE Transactions on Systems, Man and
Cybernetics - Part C: Applications and
Reviews, Vol. 28, No. 1, February 1998, pages 80-103. (Last among 10
authors.)
“Model-Based System for Engineering (T3SD) and
General Systems Logical Theory,” in
Computer Aided Systems Theory -EUROCAST'97, Springer,Lecture Notes in
Computer Science 1333, Edited by Franz Pichler and Roberto Moreno-Diaz, 1997,
pages 202-217 (Second Author with Germano Resconi.)
Subsystem
Optimization Implies System Suboptimization:
Not! electronically published at http://www.sie.arizona.edu/faculty/wymore.html, 1997.
“SYNERGY: The Design of a Systems Engineering System, I,”
in Computer Aided Systems Theory -
CAST’94, 4th International Workshop, Ottawa, Ontario, Canada, May 1994,
Selected Papers, edited by Tuncer I. Oren and George J. Klir,
Lecture Notes in Computer Science, Springer-Verlag, Berlin, Heidelberg, New
York, 1996, pages 34-45.
“Model-Based Systems Engineering,” in The Journal of the National Council on
Systems Engineering (NCOSE), Volume 1, Number 1, 1994, pages 83-92
“AGUAS: Design of an Agricultural Water Quality
System,” in Systems Engineering: A Competitive Edge in a Changing World,
Proceedings of the Fourth annual International Symposium of the National
Council on Systems Engineering, San Jose CA, 10-12 August 1994, pages
837-844. (First author with Charles
Onstad and Leonard Lane.)
“Systems Engineering Design of a Suburb,” in Systems Engineering in the Workplace, Proceedings of the Third Annual International
Symposium of the National Council on Systems Engineering, Arlington, VA, July
26-28, 1993b, pages 459-466. (Second
author with Karen Heidel.)
“Systems Engineering Education, a New
Paradigm,” in Systems Engineering in the
Workplace, Proceedings of the Third
Annual International Symposium of the National Council on Systems Engineering,
Arlington, VA, July 26-28, 1993c, pages 321-328. (Second author with Ernest A. Unwin, first
author, and William T. Scherer.)
“30 Years of Systems Engineering at the
University of Arizona,” in Systems
Engineering for the 21st Century, Proceedings of the Second Annual
International Symposium of the National Council on Systems Engineering,
Seattle, WA, July 20-22, 1992, pages 515-518.
(Second author with A. T. Bahill (first author) and P. Mirchandani.)
“Systems Engineering: The Link between Society’s Problems and
Technology’s Solutions,” Proceedings of
the Workshop on Computer-Integrated Agriculture, 8-10 January 1989,
Washington, D. C., Agricultural Research Institute, 9650 Rockville Pike,
Bethesda, MD 20814, April 1990, pages 17 - 36.
"Structuring System Design
Decisions," Proceedings of the
International Conference on Systems Science and Engineering (ICSSE'88),
25-28 July 1988, Beijing, China, Cheng Weimin, Editor, International Academic
Publishers, XIZHIMENWAI DAJIE, Beijing Exhibition Center, Beijing 100044,
China, or Pergamon Press, Headington Hill Hall, Oxford OX3 OBW, U. K., pages
704-709.
"On the Design of a System Design
Modelling, Evaluation and Comparison System," Cybernetics and Systems '88, Proceedings of the Ninth European Meeting
on Cybernetics and Systems Research, 5-8 April 1988, Part 2, R. Trappl,
Ed., Kluwer Academic Publishers, P. O. Box 17, 3300 AA Dordrecht, The
Netherlands, 1988, Pages 743-750.
"System Theoretic Foundations of Systems
Engineering," in Proceedings of The
Fifth International Conference on Systems Engineering, 9-11 September 1987,
Dayton, Ohio, Conference Co-chairmen B. A. Shenoi and W. R. Wells, IEEE Service
Center, 445 Hoes Lane, Piscataway, NJ 08854, 1987, pages 209-212.
"Design of Service Delivery Systems,"
A General Survey of Systems Methodology,
Proceedings of the Twenty - Sixth Annual Meeting of the Society for General
Systems Research, edited by L.
Troncale, Systems Science Institute, University of Louisville,
Louisville, Kentucky, 40208, 1982, pages 585 - 595.
"Applications of Mathematical System
Theory to System Design, Modelling and Simulation," 1981 Winter Simulation Conference Proceedings, edited by T. I.
Oren, C. M. Delfosse and C. M. Shub, IEEE, 445 Hoes Lane, Piscataway, New
Jersey, 08854, 1981, pages 209 - 219.
"Resolution of System Design
Problems," Proceedings of IEEE
Computer Society's Third International Computer Software and Applications
Conference, IEEE Computer Society, 5855 Naples Plaza, Suite 301, Long
Beach, California, 90803, 1979, pages 211 - 214.
"The Challenge of Large-Scale System
Design and Analysis," Proceedings of
the 40th Meeting of the Military Operations Research Society, Monterey,
California, December, 1977.
"A Real Time Decision Model for the Army
Communications Command," Proceedings
of the Thirteenth Annual US Army Operations Research Symposium, US Army
Concepts Analysis Agency, Department of the Army, Fort Lee, Virginia, 1974,
pages 680 - 695 (second author with K. Forry).
"A Systems Engineering Formulation of the
Open Pit Mine Problem," Proceedings
of the Eleventh International Symposium on Computer Applications in the Mineral
Industry, Tucson, Arizona, 1973 (second author with R. N. Zapata and B. K.
Cross).
"A Systems Engineering Formulation of the
Information and Referral Problem," Proceedings
of the 1973 Conference on Cybernetics and Society, IEEE Systems, Man and
Cybernetics Society, IEEE Inc., 345 East 47th Street, New York, N. Y.
10017, 1973, pages 6 - 7 (second author with R. N. Zapata).
"A Mathematical Theory of System
Testing," Proceedings of the Second
Hawaii International Conference on System Sciences, edited by B. S. M.
Granborg, Department of Electrical Engineering and the Information Sciences
Program of the University of Hawaii, Honolulu, Hawaii, 1969b, pages 711 - 714.
"A Model Curriculum in Systems Engineering,"
The Journal of Systems Engineering,
Volume 1, Number 2, April, 1969a, pages 291-324.
"The Construction and Manipulation of
Mathematical Models in Engineering Training," Proceedings of the Annual Meeting of the American Society of
Engineering Training, Washington State University, Pullman, Washington,
1966 (first author with S. R. Browning and G. R. Peterson).
"Numerical Evaluation of Multiple
Integrals, I," Mathematical Tables
and Other Aids to Computation, Volume XI, Number 58, April, 1957, pages 59
- 67 (second author with P. C. Hammer).
[1] The notion of scoring function is related to that of utility function, see [Keeney, 1976], and also to fuzzy set functions, see [Zadeh, 1965].
[2] See [Wymore, 1993, page 385, section 8.45]:
f(v) = 1 / (1 + ((b – m) / (v – m))2s(b + v – 2m)), where b is the baseline, m is the minimum, s is the slope of f at b and v is the variable belonging to the range of the underlying index.